Assume I have a sequence that runs until 1024 samples exit the DUT. One of my scoreboards should check only when it has all the samples that came out of the dut. Ie it can not start analysing after 1023 samples as some fft results will be messed up.
Ideally we don’t want to inform the scoreboard about this 1024 number, but trigger it’s analysis on the end of the sequence getting samples from the DUT (eg via some mailbox message from sequence to scoreboard)
Now both sequence/driver and monitor/scoreboard sample at the same clock edge. So my concern is that there could be a race between the sequence triggering the scoreboards analysis and the sample arriving in the scoreboard via the monitor.
Any thoughts on how this could be avoided? For now I can only think of:
Provide the scoreboard the 1024 number instead of triggering it of the sequence
Add some #0, nba or time in the triggering path
Let the driver sample the bus later than the monitor. (guess I could give different values for their clocking block)
I would like to avoid 3 as I am not sure how this will influence the rest of my testbed check which is highly reactive between sequences.
Option 1 has some complications as well and 2 feels awkward.
It looks like you are guessing there could something happen, right?
ON the transaction level there are no races. Races are limited to pin level in Verilog/Systemverilog. Even VHDL does not know races.
But you could triger an event after reaching the maximum number of events. This trigger can be used from any other block in your testbench.
Using #0 is not recommended because causes only 1 step forward in the SV scheduler.
Not sure what your definition of a race is, but I am pretty sure that also in testbed chest you can have a challenge of knowing which path will arrive first. In my case either dut/monitor/scoreboard VS dut/driver/sequence/scoreboard
From a functional point of view the driver should be always earlier than the monitor, because the monitor should collect the response of the DUT, right?
Sounds like your driver is actually a “slave” driver that is responding to the DUT and simply counting transactions as they come out and responding to the protocol and you’re relying on the monitor to recognize the same transactions and write them to the scoreboard.
Sounds like the simplest thing would be an event that you can trigger on the opposite edge of the clock from the driver after it sees the 1024th transaction. That should be plenty of time to make sure that the monitor has written the last transaction to the scoreboard.
Or, you could have the monitor count the transactions and notify the scoreboard when the last transaction arrives. You could do this by creating a new transaction type that includes your bus transaction and a “last” field. Then the write() method in your scoreboard could look for the “last” field and start processing when it sees that as TRUE.