Anyone Using Transaction Recording?

Does anyone out there have any experience with transaction recording?

I see that OVM provides a recording API but it appears that none of the required system calls are actually made.

I’d appreciate any feedback on a) how much work is required to implement this (using Questa) and b) how valuable this stuff is as a debug tool.

Thanks

I have not personally tried it yet with OVM in Questa but if it works as it did with the TestBuilder and SCV in the Cadence environment a number of years ago it can be a real help in debugging. It should annotate transactions to the wave form viewer at the same time as all of the other simulation signals. It also provides a mechanism to create relationships among transactions which really helps with the cause & effect bug tracking. You can also track all of the child transactions that generated from the parents. This is one of the best things that Cadence brought to the transaction based verification methodology. My guess is that when the guys that created it at Cadence joined Mentor they brought the same idea there. I would suggest trying it. Just make sure your debug environment supports the SST2 data base or what ever data base it generates these days.

Does anyone out there have any experience with transaction recording?
I see that OVM provides a recording API but it appears that none of the required system calls are actually made.
I’d appreciate any feedback on a) how much work is required to implement this (using Questa) and b) how valuable this stuff is as a debug tool.
Thanks

Hi rbailey.

The stubs are there in OVM, but then each vendor is required to supply the implementation, since each vendor may have its own API within the core of the simulator.
I can’t answer for Mentor, but for Cadence users, there is a set of OVM additional files delivered with the simulator, and these provide the implementation of things like the transaction recording. Perhaps Mentor provide a similar file with their tools?
As dont suggested, the Cadence transaction recording is the same one for SCV, OVM, Specman etc, so there’s a common look-n-feel across all the languages.

From a user’s point of view, the use model is trivial:

  1. compile the transaction recording implementation file from your simulator vendor.
  2. Declare your OVM transaction fields using the `ovm_field_* macros.
  3. Use the begin_tr() and end_tr() methods to mark the start and end times of the transaction.

Have a look at ovm-2.0/examples/xbus/sv/xbus_bus_monitor.sv for an example.

We’re currently testing an implementation to record OVM transactions
in the Questa waveform database.

It should be available in the near future as a general release.

If you are interested in this feature, please contact your local Questa
sales representative, or send an email to support@model.com and
let them know which version of OVM and Questa you are using.

Regards,
rich

Rich,

I found your post from a little over a year ago. Has transaction recording been implemented in Questa yet?

Thanks,

Scott

Hi Scott,

Yes. Questa supports transaction recording, and has for some time.
In addition, you can record OVM transactions using Questa now as well.

If you (or anyone else) is interested in a simple example, you can
run the XBUS example that ships with the OVM, just be sure when
you compile and simulate that you are using the OVM that ships with
Questa - since that OVM is tied into the Questa transaction
recording engine.

Unpack OVM to get the XBUS Example.

tar xvfz ~/Release/ARCHIVE/ovm-2.1.tar.gz

Setup Questa path

setenv MTI_HOME ...

Point at the built-in OVM with Questa.

setenv OVM_HOME $MTI_HOME/verilog_src/ovm-2.1/ # Go into the example area. cd ovm-2.1/examples/xbus/examples/

rm -rf work
vlib work

Compile

vlog+incdir+…/sv +incdir+$OVM_HOME/src

xbus_tb_top.sv

# Simulate **vsim**+OVM_TESTNAME=test_read_modify_write \ -do vsim.do -c -suppress 3829 xbus_tb_top vsim -view vsim.wlf -do 'add wave -r /*'

To use OVM Transaction recording on your own designs, make sure
you set ‘recording_detail’ to 1 somewhere in your code (probably
at the top).

set_config_int("*", "recording_detail", 1);

The example here is a trivial example running in batch, and using
post-processing. Transaction recording also works live, during
simulation. If you run into any problems, try support@model.com.

Note: MTI_HOME and OVM_HOME are not required by the tools, just
useful shorthands in this post.

Rich,

My design group’s policy is to be very wary of baking in a vendor dependency into our verification testbench. The goal seems best achieved by only using the official releases of OVM from OVMWorld.org. It’d be nice if we could have the vendor-specific files provided separately, so that we don’t put ourselves at risk of using other vendor-specific technologies without knowing it. Cadence provides a separate file (cdns_recording.svh) which we can use with any of the official releases of OVM. It’s easy to evaluate the impact of including this one file and we can easily architect a mechanism for including the appropriate files for whichever platform we’re on.

Can the mentor-specific code for recording transactions be provided in a separate package?

Scott

Hi Scott,

You can find a similar file in a Questa release called “tr_hooks.sv”.
Same idea - map a SystemVerilog function call interface to
vendor specific PLI calls which implement transaction recording.

Best regards,

rich

Great, that’s exactly what I was looking for. Thanks for your help.

Scott

Hi All,

Well this works fine for viewing transactional level informations using this begin_tr/end_tr and the config setting in the test using OVM.

But how about if the environment is purely class based not using any of the OVM constructs/components, is the the same above procedure of begin_tr/end_tr has to used with recording or any other procedure is there???

Can anybody list out the procedure for viewing transaction level info for only SV based test bench!!!

Thanks in adv,
Desperado → Coolll :cool:

I’ve used the OVM calls begin_tr and end_tr and can see the transactions in the waveform viewer but the results are inferior compared to using the built-in Questa commands, $begin_transaction, $add_attribute, etc.
For example, using the OVM calls, all the transaction class members default to 1024 bits wide and enumerated types don’t seem to be supported. Not very helpful for debug.
However, using the Questa commands, the class members are displayed with their correct widths and enum types are supported.

Anyone know why the OVM calls can’t give the same results?

Thanks.
Stewart