As I understand the architecture of a scoreboard, it should consist of a single predictor and a comparator, where the predictor receives a sequence of transactions on a single analysis port. The predictor then creates the next expected transaction, which is passed to the comparator for evaluation.
How should the predictor be designed when the state of the DUT needs to be modelled using two or more analysis ports?
My design has two interfaces, which work with distinct transaction types. The first receives a sequence of packets and generates responses. The second alters the mode of the DUT, which naturally affects the values of the responses generated on the first interface. Is it appropriate to add an additional analysis port to the predictor to cope with this scenario? Or is there another technique that I am not aware of yet?
In reply to Paul McKechnie:
The picture you are talking about (one stream, predictor, comparator) is more a theoretical one. In real life you’ll rarely have a DUT that works like that. In your case you’ll definitely need another way of getting information to your predictor.
In reply to Tudor Timi:
Perhaps my question should be rephrased as, are there any examples of how the scoreboard is actually implemented in real designs? What properties of the scoreboard are invariant and what can be changed to suit the needs of the design under test without deviating from the UVM approach?
In reply to Paul McKechnie:
I don’t think there’s much literature available on the topic. You could probably find some examples in the Verification Academy cookbooks, but even there it’ll probably limited to a device that takes input through one interface and outputs something through another interface (like the classical router example you find in most books).
There aren’t many resources available online, as companies aren’t eager to share code. The lack of free tools also doesn’t help, because it discourages hobby projects from popping up.
In reply to Tudor Timi:
Indeed, I think that you have hit the nail on the head. I have been using the cookbooks to improve my understanding of UVM and its architecture but I have found them somewhat light on the topic of scoreboards. The examples all show a single analysis port but do not suggest how it would scale for larger designs. One of the webinars that I watched regarding scoreboards also suggested that a predictor should only have a single analysis port. Hence the confusion.
In reply to Paul McKechnie:
For more stubborn designs you’re probably going to need every trick in the book: integrate your prediction components with your register models, maybe even add some references to signals (gasp!). I find that TLM purism is a bit too widespread.
In reply to Tudor Timi:
Bear in mind a scoreboard is just a comparator - what you compare is up to you. A predictor may suit or perhaps interface equivalence checking is all you need.
Over the years i have found that scoreboard architectures have adapted to the dut. E.g. i was once looking at a abstracted memory controller with 100’s of ports. I could have created a huge scoreboard, but in this case lots of little ones server the purpose with greater reuse. I have also had scoreboards with lots of analysis ports (mostly analysis fifos to decouple data from the monitors) juggling lots of comparisons
I have always found that a significant amount of scoreboard time is spent decomposing and reforming sequence_items into a common format. Some times this has been an independent easily comparable format, other times i have used the do_compare() from one of the sequence_items.
Register models are a curious case because of the UVM format used to update the register model - in this scenario my predictor and adaptors are always housed with the rest of my UVC components, well away from the scoreboard.
My answer follows your initial train of thought. Either create a configurable predictor for all DUT modes or create multiple predictors dependent on the mode of the DUT you wish to replicate. Where you put the analysis port is up to you. If you want to reuse the predictor then perhaps multiple predictors is best and allow the scoreboard to route the incoming data?
I assume your “configuration” interface is trivial enough that your could create a uvm_monitor or route the sequence_items direct from the driver. This then leads onto if you are verifying how the DUT responds to silly things on the “configuration” interface.