Hi VA,
DUT has ready/valid interfaces.
I was asked to verify that the ready output signal from the DUT works correctly.
For example: the ready signal should be de-asserted after it received 64 valid transaction.
If it is being de-asserted before this is an error.
I am not used to verify this kind of functionality.
Usually doing performance testing to verify the DUT reaches the requirements.
Never before checked functionality of the ready output signal.
Any ideas/thoughts on how this should be checked/verified?
Thanks
In reply to Michael54:
Lots of missing information.
- Are you looking do this with an assertion?
- What defines a valid transaction?
- Can there be invalid transaction in between valid ones?
- How do you know when to start counting transactions?
- When can ready signal be de-asserted? on the 64th, immediately after, or before the next transaction?
In reply to dave_59:
- Looking to do it without using an assertion.
- “Valid transaction” defined when both ready and valid signals of the interface are set to ‘1’.
- There might be cases when the ready signal is high ‘1’, but valid signal is ‘0’.
- From beginning of test, ideally would be great if this checker could be breathing and active during the whole test.
- The ready signal should be de-asserted after the 64th valid transaction.
Honestly, there might be many buffers and flops in the DUT (from experience of verifying other designs), so I wonder how this checker could be tight and correct.
In reply to Michael54:
Your last sentence makes me think there is still a lot more to your problem than you have revealed. What do buffers and flops have to do with interface signals? And when you “interface” you mean these are ports of the dut? And when does the ready signal first get asserted?
Would this work?
initial fork
@(posedge clk iff ready)
forever @(posedge clk)
if ( !ready && vcounter < 64 ) $error("ready deasserted before 64 valid transactions",, vcounter);
else if (ready && vcounter >= 64 ) $error("ready not deasserted after 64 valid transactions",, vcounter);
forever @(posedge clk iff ready && valid) vcounter <= vcounter + 1;
join_any
In reply to dave_59:
Hi Dave, will try to answer each of yours question.
Q: What do buffers and flops have to do with interface signals?
A: DUT may have additional buffers/FIFOs to handle for example: clock domain crossing. And after the CDC logic, RTL can handle 64 outstanding requests.
So these additional buffers may change the value of the present requests/entries inside the DUT from arrival to finish of processing.
For example it might have more than 64, since 2-4 entries might be present in the CDC FIFOs till it will move to other logic in the DUT for further processing.
Q: And when you “interface” you mean these are ports of the dut?
A: Correct, the ready signal (DUT output port), means the DUT can receive the valid transaction being pushed to it from other “neighbor DUT”, the transactions are captured by the receiving DUT using ready-valid handshake (same handshake the AMBA AXI protocol uses).
This what I meant in the statement “DUT has ready/valid interfaces”.
Q: And when does the ready signal first get asserted?
A: After the Reset of the DUT, all its internal FIFOs, buffers should be empty. So the “ready” output/input-port should start from high value ‘1’ - this is correct for a real full system. Since not reasonable the the DUT will start after the reset event as FULL.
In some other cases, for example: the DUT(RTL) is connected to a verification agent/stub/UVC (in block-level). This UVC should receive transactions from the DUT, using the ready-valid handshake/protocol/interface. The DUT drives the transactions using valid output port. The verification UVC “may emulate” the ready input port to the DUT (RTL), with start value of ‘0’ - after reset (this scenario is not real in a full system where only RTL blocks are connected to each other).
For example to check that the RTL is not dependent on the arrival of the ready to set the “valid” output port.
Hope I clarified all or at least most of the missing information.