I have a debate … Where to put the scoreboard/referene model…
Two options:
Put a scoreboard connected to the Bus monitor (which are the inputs to the DUT).
Put a scoreboard connected to the sequencer output.
Advantage of #1 → If you take your env to a higher hierarchy (say your DUT is now connected to a different chip and not your sequencer), then you can reuse the scoreboard.
Advantage of #2 →
More simple to code than #1. You basically don’t need to write a monitor which will translate the DUT inputs into classes.
Avoids GIGO - If there is a bug in the driver, then your DUT may get an incorrect transaction. In option #1, then the scoreboard gets an incorrect transaction too and it may not generate an error (both DUT and scoreboard gets the same transaction, but this was not the original intent of the test…).
I think #2 is the right thing to do, but appreciate any inputs…
What do you think?
Interesting arguments for option-2 however we at CVC strongly recommend option 1 for the very reason you’ve mentioned about reuse primarily and also for others. On your Option-2 “pros”, here are my counter-arguments:
Simple → For standard protocols you can pretty much get an off-the-shelf VIP for this internally or externally. So the effort maynot be all that hard.
This is new argument for me atleast. As far as DUT & SBRD gets same transaction/waves we are good - usually. On catching UVM Driver level bugs, we strongly suggest you use assertions bound to the interface. We showed this in one of our recent webinars (see: Verification Course Blog | VeriLog Courses | CVC), and I will be covering this very topic early Jan at IIT Mumbai as part of VLSI Design 2014 conference (see: http://www.vlsidesignconference.org/ It is a half-day tutorial on Sunday Jan 5th).
Maybe reading this blog is good. The posts has the good debates on exactly the same topic.
By the way, I always strongly recommend option-1, as it will not only ensure the seamless re-usability, but it will also ensure if you are verifying your IP correctly at your IP level. As, if you go with option 2, you can’t 100% ensure that your driver exactly drives what you sent through the sequencer.
That is why it is important to have the monitor as it will ensure that your driver drives the stuff correctly.
Thanks Baser! So you are JL Gray and I’m Kevin :-)
But if you want to make sure the “driver drives the stuff correctly” I think you need to choose option 2 and not option 1…
For example, lets assume you wanted to inject a good packet, but for some reason, the driver corrupted it… in this case, your checker (in option 1) will not fail, because you expect a bad packet not to be transmitted out from the chip, while in option 2, you will get a failure.
What do you think?
You are welcome! You brought a valid point, by the way. Which I believe it usually applies to the scenario where the verification engineer him/herself is the one who develop the UVC Agent.
In this scenario there might be some bug on either the driver or monitor or both of them, if the UVC Agent is not fully verified. Usually when I develop an UVC Agent, I will compare the monitor’s output to the sequence item that I send to the driver (through sequencer). And if the UVC is fully and extensively verified, then the scenario that you mentioned should be able to be caught by the monitor (protocol violation due to bad transaction observed), and/or by the scoreboard. Where the scoreboard may wait for some egress packet to be captured on the DUT egress port, which may not happen due to maybe the DUT drop the bad packet and doesn’t send anything on the egress side. This is just an example of one of the scenario. There maybe some other scenario.
As to conclude my opinion, I strongly believe that when the UVC Agent is complete (fully verified), the bad packet shall be captured anyway and the error from either monitor and/or scoreboard shall happen. And it is always better to do all of the complicated works and details implementation as much as we could in the IP level verification as long as someone choose to use UVM for their verification. It is to ensure that everything will be 100% reused when the IP is integrated in cluster/sub-system/SOC/FC level. As, it is really troublesome and really extremely time consuming if we want to enable something that is missing on the environment of the IP that we integrate in the higher level verification. I’ve gone through this so painfully… :(
Hi Baser,
so you are saying you have a checker between the monitor-out and the driver-input? If so, then my scenario will be captured there, but I can not see any other place my scenario will be caught.
… now adding another question - Is there any difference between the DUT and the monitor? It seems to me that if I’m writing a monitor I will end up writing the same exact logic written in the DUT, no?
I’m a little of a beginner in UVM, so apologize in being too basic…