This section discusses the requirements and e code for the monitor object.
The monitor object is implemented in the form of a protocol checker (sbt_checker). Requirements for the sbt_checker are as follows:
If a packet is driven to the SBT with bad parity, expect that the output signal err is asserted 1 to 10 cycles after packet end.
When the DUT signal, suspend_data_in rises, it must fall within 100 clock cycles. The suspend_data_in signal indicates that there is too much congestion in the router and it cannot accept more data.
When the DUT signal, vld_chan_X (vld_chan_0, vld_chan_1 or vld_chan2) rises, the input signal, read_enb_X (read_enb_0, read_enb_1 or read_enb_2) should rise within 30 clock cycles.
When the SBT DUT signal, vld_chan_X (vld_chan_0, vld_chan_1 or vld_chan2) is asserted (high), and the read_enb_X (read_enb_0, read_enb_1 or read_enb_2) is also asserted (high), the DUT signal channelX (channel0, channel1 or channel2) should not be tri-stated (high-z).
Temporal expressions must be created to build the monitor object. A recommended technique is to create events for simple temporal expressions. These events are then combined to form complex temporal expressions.
File contains e code for the monitor object. In this file the monitor object is not a separate unit. In this case it simply an extension of the sbt_driver and sbt_receiver objects. <' -- Extend the sbt_driver for protocol checks extend sbt_driver { -- Declare events bad_parity and err_rise event bad_parity is true(cur_packet.packet_kind == BAD)@packet_ended; event err_rise is rise('err')@clk_fall; -- "If a packet is driven to the SBT with bad parity, expect that the -- output signal err is asserted 1 to 10 cycles after packet end" expect @bad_parity => {[0..9]; @err_rise} @clk_fall else dut_error("A packet with bad parity was driven into the SBT ", "but the err signal was not asserted."); -- Declare simple events event suspend_data_rise is rise('suspend_data_in')@clk_fall; event suspend_data_fall is fall('suspend_data_in')@clk_fall; -- "When the SBT DUT signal, suspend_data_in rises, it must fall -- within 100 clock cycles." expect @suspend_data_rise => { [0..99]; @suspend_data_fall; } @clk_fall else dut_error("The suspend_data_in signal was asserted for more ", "than 100 clock cycles."); }; -- Extend the sbt_receiver for protocol checks extend sbt_receiver { -- Use computed names using the port_no field since we have multiple -- receivers event vld_chan_rise is rise('vld_chan_(port_no)')@clk_fall; event read_enb_rise is rise('read_enb_(port_no)')@clk_fall; -- "When the SBT DUT signal, vld_chan_(port_no) rises, the input -- signal read_enb_(port_no) should rise within 30 clock cycles." expect @vld_chan_rise => { [0..29]; @read_enb_rise; } @clk_fall else dut_error("For port ", port_no, " the read_enb_", port_no, " signal did not rise within 30 cycles of the rise of vld_chan_", port_no); -- Event when both vld_chan_X and read_enb_X are asserted event vld_chan_read_enb_assr is true(('vld_chan_(port_no)' == 1'b1) and ('read_enb_(port_no)' == 1'b1))@clk_fall; -- Use @z to check if any bits in data signal are high-z event data_high_z is true('data@z' != 8'h00)@clk_fall; -- "When the SBT DUT signal, vld_chan_(port_no) is asserted (high), -- and the "read_enb_(port_no)" is also asserted (high), the output -- DUT channel(port_no) should not be tri-stated (high-z)." expect not(@data_high_z) @vld_chan_read_enb_assr else dut_error("For port ", port_no, " the data had a tri-state ", "value during the time that vld_chan_", port_no, " was asserted."); }; '>
Example 13-5 illustrates e code for the monitor object.