A scoreboard is only as good as its prediction. In the first DMA bench the prediction is one line inside the scoreboard, word ^ key, and that is fine until the day the architects hand you a C model, or a second team wants to feed a built-in comparator, or you need a deliberately wrong prediction to prove the checker can fail. Each of those means editing the scoreboard. This topic moves the prediction into its own component, calls a C model from it, and then looks hard at the comparators UVM ships, one of which passes eight wrong predictions without a word.
Build a predictor that turns observed register traffic and input words into expected items, with the model in one virtual function that a factory override can replace.
Decide between a transaction-level and a cycle-accurate model, and model the register rules the DUT really applies.
Call a C reference model through DPI-C: the import, the type mapping, open arrays and chandles, and the compile flow on Verilator and on commercial simulators.
Use `uvm_in_order_comparator` with a comparison policy, explain why `uvm_in_order_class_comparator` needs do_compare, and know when a hand-written scoreboard is the better tool.
Lesson | What it covers |
|---|---|
dma_predictor and dma_env_check: why the model is its own component, what versus when, register state, ambiguous specs, and keeping the model independent of the RTL. | |
dma_model.c and dma_dpi_test: imports and type mapping, open arrays and chandles, the extern "C" link error, compile flows, and a C model that hangs the simulation. | |
uvm_in_order_comparator with a policy class, the class comparator that matched eight wrong predictions, the algorithmic comparator, and when built-ins lose to a scoreboard. |
Read Scoreboard Architecture first if you have not: these lessons assume the expected-versus-actual model and change only where the expected side comes from and who compares.