I am writing an UVM scoreboard verification component.
I would like to verify it as a standalone before integrating.
Is there a recommended way or any simple framework available to verify UVM agents/components in a standalone manner?
In reply to verif_learner:
This is a very broad (every design is different) and deep (who verifies the code that verifies the scoreboard). At a minimum, you should be able to check the connections, have your monitor send random data and make sure your scoreboard is receiving all the transactions it needs to perform its checks. In some cases, you can use your predictors to generate both actual and expected data. Then randomly disturb the actual data to make sure the scoreboard catches the error.
In reply to verif_learner:
I am writing an UVM scoreboard verification component.
I would like to verify it as a standalone before integrating.
Is there a recommended way or any simple framework available to verify UVM agents/components in a standalone manner?
I think it is not a good idea to verify UVM components in a simplified environment. Most complicated are thecomponents connected to the DUT, i.e. driver and monitor. With the exception of the compare function in your scoreboard all other components are quite easy.To avoid errors in your environment it is strongly recommended to generate your UVM environment automatically. Then you can focus your efforts on drivers and monitors as well as your scoreboard.
In reply to dave_59:
Sorry, my question was not clear.
I do understand what to test for the component I am designing.
Is there any framework or reference code that I can use to instantiate the scoreboard and quickly do some sanity test?
PS: while looking into this, I found svunit?
If this something I can use?
In reply to chr_sue:
chr_sue,
the scoreboard will get verified in the full testbench context.
But as the scoreboard is complex, it always makes sense to do some standalone verification before integrating it in the testbench
In reply to verif_learner:
Just an update on this topic.
I found this site while searching for options to test a standalone uvm component.
In reply to verif_learner:
A scoreboard is never really complicated. You are comparing data streams of the same type which arrive at different times.
In my scoreboards I do the following before writing the compare function. I print out the data streams coming in and have to be compared. Then you see if there is an offset in the data or not. This might be the issue happening most often.
In reply to verif_learner:
Yes, SVUnit is a good approach in checking the operational functionality of your scoreboard.
In reply to chr_sue:
ok. terminology issue from my side. What I called scoreboard is actually a checker that calls reference models, has a bunch of call backs for user fine tuning and then comparison.