IMPORTANT NOTICE: Please be advised that the Verification Academy Forums will be offline for scheduled maintenance on Sunday, April 6th at 2:00 US/Pacific.
Hi, I am learning UVM and trying to write a testbench for asynchronous FIFO.
I am writing on edaplayground : EDA Playground
The issue :
I am trying to ignore the transactions that are received by the driver while reset is asserted (active low).
When reset is de-asserted, the driver should drive the transaction to the DUT.
However, the TB only works when reset is asserted. As soon as reset is de-asserted, the simulation gets stuck and driver does not receive any more transactions.
The reset is driven through the interface by the top module
Reviewing your code shows a lot of weaknesses. It looks like your code is acopy/paste from different sources.
A few things I want to address:
(1) Never use signals in the scoreboard. Make sure transactzions are only transmitted in the operational mode.
(2) your uvm_info statements are not clean. Use $sformats for the 2nd argument. (3) uvm_info displays the time. You do not have to take care for this in your code.
(4) You are using heavily `includes which is not a good coding style. Package your code into packages and import them.
(5) your reset handling in your code is wrong.
Great inputs from @chr_sue above. The core issue of hang is in your Scoreboard, look at what you are doing when rst_n is deasserted - you have a zero delay loop. Also, your code wouldn’t compile on other tools that are strictly IEEE 1800 LRM compliant - such as your modport FIFO does not expose full, empty but your DUT drives them - just as an example.
Thank you so much for taking the time and pointing out the issues in the code. Your feedback is much appreciated! Can you please elaborate a bit on your point number 1 and 5?
Thank you, I couldn’t have noticed the infinite loop on my own. Thank you for pointing it out! And yes, I am painfully aware of my bad coding. Hoping to get better with time! Thank you so much for your time and reply.
Thank you for your inputs. I noticed that you removed the reset condition from the scoreboard. Also, response by @sri.cvcblr was helpful, following which I introduced an additional wait statement in the scoreboard to wait for write queue or read queue to receive transaction from the respective monitors (right now I have not implemented reading operation but writing works) which got rid of the infinite loop. The testbench now works.
However, this lead me to experiment and assert the reset signal a second time after initial reset. I found that this second reset is not registered by the testbench at all and the scoreboard also does not clear the queues. As you also pointed out, my reset handling is definitely wrong.
Any advice/suggestions given will go a long way for my learning journey.
Two additional things:
(1) why are you using queues in your testbench instead of tlm_analysis_fifos? Using them makes your scoreboard mor easy.
(2) Of course you can observe any reset signal during your simulation and flushing the analysis_fifos.