In reply to cuonghle:
In reply to warnerrs:
Hi Ryan, Chris:
Thanks for your reply.
Quote:
I forgot about the case where only the paused sequence is trying to send items. Still, QoS is a form of arbitration, so putting it in the sequencer is a natural fit. If this scenario requires that the paused sequence stay paused, even when there are no other sequences trying to send items, then the UVM_SEQ_ARB_STRICT_* modes won't work.
Yes, the paused sequence will stay paused as long as DUT (slave-side) is asserting pause to the driver.
What I have implemented is whenever the paused sequence detects the pause signal (I did a signal probe from my sequence, though I know this is not a proper way), it will skip the current packet generation and advance 1ps (to prevent dead loop). This is what my sequence looks like
task body;
int seq_qos; //indicate which qos this sequence represents
...
while (generated_pkt < pkt_to_send)begin
...
if(dut.pause[seq_qos]==1) begin//pasue is bitmap based pause
#1ps;
contiune
end
else begin
start_item(req);
finish_item(req);
generated_pkt++; //only increase when a packet was truly generated
end
end
However, from what I observed from the waveform, when DUT paused qos0, even though I did see sequence 1-3 is able to generate packets for qos1-3, but it was driving at a much slower speed. (I am expecting sequence 1-3 to generate at full speed, but the actual speed is 10x slower)
In that case, I think I should write my own arbitration_policy for my sequencer. But I wonder why detecting and adding the 1ps delay (my DUT clock cycle is 1ns) in seq0 will significantly slow down the traffic generation for other sequences?
Thanks for all your help,
Hao
