Methedology

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

  1. Pass the transaction directly from the sequencer to scoreboard
  2. Monitor the input bus to DUV and recreate the actual transaction.

I have got a suggestion that the first method shouldn’t be followed. But the second method is time consuming and why should I build the actual transaction based on the interface values?

The only reason to capture the input transaction from the input bus would be to capture any error conditions or other “massaging” you might do in the driver to modify the transaction from what you got from the sequence via get_next_item(). If you’re not doing that, then you could pass it directly from the sequencer.
Since doing that requires actually extending the sequencer, I usually recommend sending the transaction out an analysis_port in the driver. It does the same thing, but allows you to better replicate timing and include any other driver-specific information if you want.

In reply to tfitz:

as to me, it’s not only because of possible errors we can make in driver, but also for a vertical reuse of the test system. For example, if we connect DUT with another module, that sends input data for it, our testbench should not make any transactions, and so the only way for scoreboard to collect input data is to take it from the input interface.

Good point. In a vertical reuse situation, you’d need a monitor on the DUT input interface as trogers mentions. Since you’ll have to make one at some point, you may as well create a monitor for this interface and use it from the beginning.
You may find it advantageous to wrap your monitor(s) and scoreboard in a single component to simplify the top-level environment, but that’s really up to you.