Is it a proper way to pass the sequences directly to scoreboard from the sequencer, with out any monitor?
I need to connect sequencer to scoreboard through ports. But since the sequencer don’t have any run phase, I couldn’t write the port in sequencer. So I need a port mechanism which can get the sequence from the sequencer with out the need of a port write in sequencer. That is why I used pull_port. Please suggest some feasible solution for my requirement.
please give me an example showing the declaration of the ports and the connection between scoreboard and sequencer.
You should never connect a sequencer to a scoreboard. Transactions sent to a scoreboard should only come from a monitor.
The reason for this is that the scoreboard should reflect the behavior of the DUT based on the inputs applied to it. Since the sequencer is generating stimulus and not applying it to the DUT, it shouldn’t connect to the scoreboard.
Monitors will capture the stimulus applied to the DUT, hence the connection from the monitor to the scoreboard.
Also, from a reuse standpoint, there are times when you will use your agent in passive mode and the sequencer won’t be used. However, the monitor will be used.
Thank you cgales for the reply. I shall explain why i’m trying t send the transaction to scoreboard.
I’m trying to verify usb2.0 IP core. For one of the modes of operations, i need to generate 1024 bytes of constrained random sequence which i pass to AHB driver. The AHB driver will pass the sequence 32 bit at a time to the interface. Now I have a monitor, which monitors the response from the DUV and generates the high level transaction based on the same. Now I need to compare this high level transaction with the actual transaction I have generated. I can get the actual transaction in two ways
Pass the transaction directly from the sequencer to scoreboard
2.Monitor the input bus to DUV and recreate the actual transaction.
The second one is the procedure you are suggesting. But it is time consuming and why can’t i directly use the transaction i generated directly in scoreboard when it is available ? Can you please explain
Although the customary way of providing stimulus sequence items to a scoreboard is with a monitor that is monitoring the port signals into the DUV and packing them into transaction objects, I personally think it’s a waste of time and resources to do so when it is perfectly reasonable to pass these sequence items to the scoreboard by broadcasting them on an AP in your driver. Just make sure the objects are exactly what the driver is sending to the DUV. This is especially true when the agent is connected to a bidirectional port and is already using a monitor to collect outbound traffic.
I would never send from driver to scoreboard. Doing so makes the assumption that everything will always go perfectly on the bus: that the driver will never have a problem sending, that the DUV will never generate unexpected behavior (including a hung bus). If you can safely assume your DUV is flawless, why are you testing it? And even if you claim that - are you also willing to claim that your driver is perfect, as well as the system of {DUV+driver}?
Now, when something does go wrong: do you want to debug using what you expected to have happen on the bus or what actually happened on the bus?
Constrained random testing is all about testing cases we never thought of. That includes finding bugs in the testbench as well as DUV. Debugging using what you planned to see on the bus vs. what actually happened is in conflict with the costrained-random paradigm.
You make good points; sending transactions to the scoreboard from the driver should be done only if you can be sure the driver will get the transaction on the bus perfectly, and that the bus protocol is straightforward enough that nothing the DUV can do will interfere. In my specific case, I am driving an internal bus downstream of the serdes logic. If I snooped this bus with a monitor, and the driver made a mistake , it would result in problems in the monitor that would alert me to the situation. Currently, I am using assertions in the RTL to flag any protocol violations on the bus being driven by the driver. I must agree that , in a general sense, your advice is sound!
Not that I’m paranoid - but I’m famous for being the person who hits the CTD bug in software that has been released for months and totally stable.
If you’re relying on assertions: I strongly recommend using svunit to verify that your assertions will actually fire when you expect them to, and that your monitor properly copes with abnormal bus events.
I’ve been surprised at how many assertions I’ve encountered that didn’t fire in corner-cases, or the enable was connected with opposite polarity.
I have same sort of confusion . Once your create a higher level transaction, that will be received by lower lever sequence and will be converted into a low level transaction (AHB Transaction) . It may happen that each of these higher level transaction will generate multiple AHB transaction . Don’t you think that reconstructing this higher level sequence by monitoring multiple AHB sequence seems like a difficult job? .At least for me just by reading the DUT register or AHB transaction and to figure out what DUT is doing in-terms of higher level abstraction is sort of impossible.
The goal of your test environment is to accurately predict how your DUT will respond based upon the stimulus provided at the DUT boundary, not based on any higher level of stimulus.
When you see an AHB transaction being written to your DUT, your scoreboard should receive that transaction from the monitor and determine how your DUT will respond. This may cause only a configuration change by the DUT (i.e. a configuration register write) and generate no response. Or, it might cause the DUT to generate a transaction (i.e. writing to a start bit) on another interface.
The scoreboard model of your DUT should be functionally equivalent to the actual DUT, except that it uses TLM for the stimulus instead of pin level stimulus.