Reply To: Scoreboard user guide?

Why OSVVM™? Forums OSVVM Scoreboard user guide? Reply To: Scoreboard user guide?


Hi Martin,
these are the OSVVM packages:
AlertLogPkg.vhd MemoryPkg.vhd NamePkg.vhd OsvvmGlobalPkg.vhd RandomPkg.vhd TextUtilPkg.vhd
CoveragePkg.vhd MessagePkg.vhd OsvvmContext.vhd RandomBasePkg.vhd SortListPkg_int.vhd TranscriptPkg.vhd

And the word “coreboard” appears just once in it :

The relating function just decides about what AlertLog_ID belongs to the Scoreboard, That’s all.
So, what “scoreboard package” are you refering to? There can’t be documentation for a non-existing package.

You also say that you have printed training material. From what source? Is there such a package mentioned or provided that is yet unreleased for OSVVM? Don’t you have a cheap scanner somewhere around that can convert it into a PDF? Any multifunctional Priner/Scanner should be able to do this automatically (There are tools to merge front and back pages if you have no double side scanning device).

The Scoreboard does NOT check the responses from the DUT and compares to a reference value.
(That’s why it’s called Scoreboard and not OutputCompare)
It just keeps track of the results coming from some checks.
These might be acheived by comparing output values to some reference value (or reference model output).
But also PSL-Assertions or similar VHDL Checker functions might contribute to the Scoreboard.

The actions that are needed are also done using the coverage functions.

Say you have a module with an output value and a number of working modes.
Then you can create a covergroup that combines the modes with the output values (Crosscoverage).
(If there are impossible or unexpected output values, you can use IgnoreBin or IllegalBin to deal with it.)

Then you may have some loop like this:

if OutputCheck.IsCovered loop
wait until OutputValid = ‘1’;
If CompareOutput() then
— maybe do some loggging
–Error Actions here
— But this makes only sense if the errors are non critical and the testbench continues
end loop

Once all output values in all modes appeared correctly you are done.
How fast that happens depends on your input stimuli.

Remember what you said :”… the coverage package, which only keeps track of what is tested, …”
Right, and that is not limited to stimuli, but also holds for verified results.

Just imagine: Due to some mistake your Testbench fails to change the modes.
From viewing your stimuli everything might look good and well covered.
But your OutputCheck Coverage will never complete and with a simple look at the Coverage report you will see the missing mode change appearing in the OutputCheck Covergroup.

I hope this was helpful.

Have a nice simulation