This is more of a methodology question. OVM formally defines scoreboard as one of the component of the testbench. I believe scoreboard, as the name suggests, is mainly used to store some info and verify that data was eventually sent by the DUT. The checker is probably much more general term. It probably includes scoreboard also since that verifies some DUT function. But assume DUT transforms the data (like in dsp for example) then a simple scoreboard will not work. In such cases, does one include the tranform function inside the scoreboard and compare the data after applying this transform function. Or a bigger entity controls the scoreboard and it interfaces with it to get the data, apply transform and then compare. The scoreboard acts as slave to checker. I would like to know how checking is done when such transforms are involved?
I see scoreboard as a checker.
Which means, any kind of data transformation is also done inside the scoreboard.
I do DPI C calls in side my scoreboard.
The scoreboard gets data from the monitors (via TLM FIFO) and then generates the expected data.
I think, the confusion is created because of the new class ovm_scoreboard.
I guess, that is just to differentiate various components.
Mulitiple people will give multiple names for the scoreboard. Example: sb, checker, etc.
So, if a new person joins a group, it is difficult for him/her to find out the scoreboad module.
So, if the scoreboard is extended from the ovm_scoreboard, you can grep for it easily.
And BTW, if you look at the source code of ovm_scoreboard, there is nothing.
Its just ovm_threaded_component.
You are correct that ovm_scoreboard is a threaded_component to make it easier for users/tools to recognize the scoreboard. The OVM includes two components that can compare two transaction streams, which is the usual operation of a scoreboard.
ovm_in_order_comparator takes two transaction streams and compares them in-order. It actually includes two analysis_fifos (before and after) and pulls out transaction pairs to compare them.
ovm_algorithmic_comparator takes two transactions streams and performs a transform operation on one before comparing it to the other.
These two comparator components can handle a lot of situations. For others, you can use an ovm_scoreboard and implement your own. You may even want to include a comparator inside an ovm_scoreboard (making the analysis_exports visible) and add other stuff as well. It’s up to you.
You are correct that ovm_scoreboard is a threaded_component to make it easier for users/tools to recognize the scoreboard. The OVM includes two components that can compare two transaction streams, which is the usual operation of a scoreboard.
ovm_in_order_comparator takes two transaction streams and compares them in-order. It actually includes two analysis_fifos (before and after) and pulls out transaction pairs to compare them.
ovm_algorithmic_comparator takes two transactions streams and performs a transform operation on one before comparing it to the other.
These two comparator components can handle a lot of situations. For others, you can use an ovm_scoreboard and implement your own. You may even want to include a comparator inside an ovm_scoreboard (making the analysis_exports visible) and add other stuff as well. It’s up to you.
-Tom
Hi Tom,
The ovm_algo… is also an in-order comparator. Its only that comparison happens after data transformation. I am not sure if these 2 comparators can handle fair amount of situations. Most of the network processors I have worked on, the order of data transmission cannot be predicted. It all depends on when some deeply buried block saw a request or first word of data etc.
I am not sure if these 2 comparators can handle fair amount of situations. Most of the network processors I have worked on, the order of data transmission cannot be predicted. It all depends on when some deeply buried block saw a request or first word of data etc.
Any comments?
You are right that there are situations that require more advanced checking than is provided by the ovm*comparators. Unfortunately, those are often application-specific. One can use the comparators as a template from which to develop your own. As an example, the scoreboard could take that tranactions out of the analysis_fifos and put them into an application-specific data structure (such as an associative array) and process them as needed.
You are right that there are situations that require more advanced checking than is provided by the ovm*comparators. Unfortunately, those are often application-specific. One can use the comparators as a template from which to develop your own. As an example, the scoreboard could take that tranactions out of the analysis_fifos and put them into an application-specific data structure (such as an associative array) and process them as needed.
Thank you. Is there an example that shows the use of comparator?
I had great success using the “generic” ovm_in_order_class_comparator as a way to offload all score-keeping and reporting tasks and not having to write them myself.
I wrote my “before” and “after” monitors such that both have the same transactor class as output to the comparator. In that case I can use the generic OVM in_order class comparator, which in turn is using the “comp” method defined in the transactor to actually compare the results.
Rather than dealing with the entire comparator, I can spell out my compare rules in “comp” method of the transactor class, including such things as parameterized missmatch tolerances and reporting levels.