I modified the SPI OVM testbench that can be downloaded from Mentor's web site. The testbench is customized to test our design. I have been using Mentor's Questa tool to run simulation while we evaluate the tool. The testbench has worked with Questa. We are also evaluating Cadence's Incisive. I started to compile and run simulation with Incisive. It apprears to compile OK but $cast does not seem to work right.
seq_item_port.get_next_item(req); $cast(cloned_item, req.clone()); ap.write(cloned_item);
This works fine with Questa but not with Incisive. The data members in req are defined but not cloned_item after $cast.
Is there any reason that this does not work with Incisive? Questa was sourceing OVM-2.1.2 source code.
Without seeing definitions for "req" and the classes it uses, it's impossible to say why this doesn't work.Are you certain that the data members have all been registered with OVM such that they would be copied?
I would have expected it to work provided the declarations were correct.
In reply to StephenH:
Stephen, thank you for your response. I had to comment out some data member functions in the seq_item class because Incisive gave errors about unpacked array for convert2string and do_record functions. (This was not an issue with Questa.) I also commented out do_copy functions thinking that they are not used. I think you are right, this caused the problem. I thought clone function was not working properly, so I replaced the clone function call with "create cloned_item and do_copy" after uncommenting out do_copy function in the seq_item class. This worked. After reading your post, I switched back to "clone". This works, too! I didn't realize that "clone" is using "do_copy" function but this makes sense. If my analysis (guess) above is incorrect, please let me know.
In reply to mwhite:
If I recall correctly (it's a while since I looked at the OVM code), clone() just wraps around copy(), simply adding the new() to create a new object. Otherwise you'd new() your class yourself and call copy().
Regarding SV construct support, do make sure you're using the very latest Incisive version as R&D are rapidly filling in the remaining gaps where we're missing bits. The latest is 10.20.034 if you're looking for SV support. Oh, and make sure you bug your local Cadence AE about any missing SV constructs; the more we hear about what's a priority for users, the sooner we fix the problems ;-)
BTW, if you're looking at Mentor code, be aware that they prefer not to use the OVM macros, so you're left doing more of the boiler-plate code yourself (e.g. implementing do_copy()). If you use the OVM automation macros like `ovm_field_* then much of the boiler-plate is taken care of, which saves you a lot of extra code (thus less risk of bugs in your TB). Either approach is valid, with or without macros, but Cadence always recommends to use the macros.
Just a few! ;-)
When the OVMWorld.org website was still vendor-independen, you would have found the Cadence-contributed OVM reference methodology kit on the user contributions page. Mentor now run the OVMWorld site and have blocked Cadence from accessing it, so I don't know if Cadence's contributions are still accessible there.
You can certainly find the UVM equivalent on UVMWorld.org (this site is owned by Accellera so should remain vendor-independent).
There is also a wealth of OVM / UVM material shipped with Incisive, as part of our SoC Verification Kit. The Kit is basically a full SoC design using lots of Cadence's own design IP, almost entirely open-source. We provide not just the example testbench code but also full self-paced workshop / training material for pretty much all verification flows (block-level OVM/UVM, block-to-system reuse, hw/sw co-verification, formal properties, lo-power etc etc). The best thing to do is crank up the help tool "cdnshelp" from your Linux/Solaris prompt.In the hierarchy of help pages, look for "Incisive Verification Kits". Hopefully the image will attach here to give you a pointer to it.
We use these workshops to deliver training, so they're really comprehensive. Plus the Kit contains a lot of "free" VIPs to give you good examples to get you moving (of course our commercial VIPs are a league above this in terms of features, support etc, but that's another story ;-) )
I encountered another issue related to do this. The cloned_item gets written to "ovm_analysis_port" and connected to "analysis_fifo" in the receiving end. This received item will not be processed until new cloned_item is written. I displayed some content of the received data when it gets from analysis_fifo. It still has 1st item data information. Then a new cloned_item gets written. Then the receiving end intends to process the 1st item data, it does no longer have 1st item data information, it has 2nd item data. The receiving end gets the item only once from analysis_fifo, so it should not be reading the 2nd item.
It appears that the cloned_item carries "reference" information not deep copied information. Is this supposed to work this way? If yes, how can I make sure that analysis_fifo will have "deep copied data" rather than "reference" information? If not, what could I be doing wrong to get this result?