Is it a good idea to share a single driver between the DUT and the Model ? The model is similar to the DUT at the pin level.
If I create two instances of the drivers, there is no sync. Since the DUT’s driver pops off a transaction with get method and its no longer there on the channel. When Model’s driver asks for a transaction, it receives completely new test.
As a fix, I am using the same driver. Driver instantiates the DUT and the model at the pin level and provides the test stimulus to the both at the same time.
I am not sure if its a good practice though.
So how to ensure that the DUT and the model receive the same test stimulus ?
Would like to know the way its done out there.
Hi,
I am not sure whether there is a special reason for you to use a pin-level model, usually we use transaction-level model and the model get transactions(stimulus) from the monitor through TLM ports.
Yes, the model can be a high level transaction level model.
But in that case, model won’t have the “timing” right ?
For example, if I generated 100 randomized test cases and provide it to the DUT and model at transaction level,
the DUT will take certain amount of time to provide a result. Do I have to hold the operands at transaction level
somewhere, and provide to the transaction level model once DUT gives a response and then compare ?
Or is TLM takes care of that ? Since its FIFO based ?
Yes, the model won't have the "timing".
The model and the DUT will run parallel, once the monitor extract a transaction from pins, it sends the transaction to the model and the model will process the transaction and then send the result transaction to the scoreboard through TLM port.
There is also a monitor running to extract the DUT output pins, it sends the DUT output transactions to the scoreboard by TLM port too.
The scoreboard MAY either hold the result transactions till there are enough transactions to commit a comparison or commit a comprison each time it get a transaction from the DUT.
So the way I understood is, the model is located in between a monitor that extracts transaction from pins (input pins of DUT I suppose). This monitor looks for any change on DUT input pins, when change is seen, new stimulus is applied to the model. Since model does not have timing, model will compute the result right away and send it to the scoreboard.
The other monitor, that collects output of the DUT and sends to the scoreboard. Scoreboard already received the output from the model above. I guess scoreboard will not request a transaction from model unless result from the DUT is available, essentially using TLM as buffer. Then it will compare and raise exception if results don’t match.
correct, but still something more I want to interprete about the scoreboard.
“I guess scoreboard will not request a transaction from model unless result from the DUT is available, essentially using TLM as buffer”
We usually use a tlm fifo in the scoreboard, once the model output a transaction, it'll be writen into this fifo. When to get this transaction will depend on the way you implement your comparison. In some complicated cases, we will use a queue to buffer these transactions untill the condition for comprison met.