Hello OVM Developers,
Kudos for such a Herculean task of working across competition to release OVM jointly. Here are my quick comments after some quick/15 minutes look. I thought I will share it and trigger a technical thread!
OVM does look like a nice amalgamation of AVM + uRM (as promised in earlier press releases). For instance some of the base class names like ovm_component, ovm_transaction, ovm_transaction::clone etc. are AVM like.
The macros seem to have been inherited from uRM - though macro debugging is painful, as demonstrated by Kelly’s VMM-to-uRM paper, it saves lot of coding in terms of “copy/clone, compare/pack” etc. This I would say is a clear advantage that OVM (and uRM) brings in! Here is a brief list that I could put together relating their origins – not sure what’s the worth of this list, but FWIW – here it is
On the downside, the weak random_stimulus_generator still seems to be the same - it is not like a vmm_xactor that can be easily paused, restarted etc. For instance if I want to send few random and few directed and again random - the built-in ovm_random_stimulus class can’t do it. Sure one can write own code, but this is something I’m so used to with VMM. May be OVM2.0 will have it!
Also the $cast is used quite a bit with no error checking - the success of $cast is not being looked at.
For instance if I want to send few random and few directed and again random - the built-in ovm_random_stimulus class can’t do it. Sure one can write own code, but this is something I’m so used to with VMM.
Ajeetha, CVC www.noveldv.com
Ajeetha-
The sequence mechanism provides this capability with reuse in mind. In OVM, two leaf sequence classes can be created: one that does a variable(and controlled by the user) number of random transactions and then one that does the desired directed transactions. These two sequences can be reused in another sequence that executes the random sequence followed by the directed sequence followed by the same random sequence. This sequence of sequences can then be reused in larger sequences to create even more intricate transaction scenarios. The two leaf sequences are also available for use in other sequences. The return on the investment of creating these sequence classes is quickly realized at the test writer level when creating sequences and tests that target different functionality while still maintaining the Constrained Random philosophy. By leveraging OVM sequences, you are able to cleanly separate sequential stimulus specification from the testbench component hierarchy, and this greatly facilitates reuse.
Regarding your comment above about $cast(): The OVM philosophy is to check the return of $cast() in cases where it might fail. However it does not need to be checked in some cases since it is known that the cast will succeed because the code dictates that one class is a subclass of another.
Ajeetha-
Regarding your comment above about $cast(): The OVM philosophy is to check the return of $cast() in cases where it might fail. However it does not need to be checked in some cases since it is known that the cast will succeed because the code dictates that one class is a subclass of another.
From a best practices standpoint, if a function can return error status the return value should be checked.
From a best practices standpoint, if a function can return error status the return value should be checked.
Well, error checking is only really a useful best practice if you have a plan to handle the error. What do you do if a cast that can’t fail by design fails? With SV attempting to dereference null will result in a simulator stop with a line number which is probably exactly what is required here…
One could either explicitly cast the return of cast to void - then it’s clear that the return status is not to be checked or do something similar to what’s done to check the status of calls to randomize() - simply put the whole expression inside of an assert() statement. Then a graceful error will be displayed in the impossible situation of the cast failing ;)
One could either explicitly cast the return of cast to void - then it’s clear that the return status is not to be checked or do something similar to what’s done to check the status of calls to randomize() - simply put the whole expression inside of an assert() statement. Then a graceful error will be displayed in the impossible situation of the cast failing ;)
Not quite, $cast is one of those special SV functions that behaves differently if you call it as a function vs a task. Casting to void or using in an assert expression actually prevents it from generating its own error report.
What is in ovm really is best… $cast as a task, when it fails will cause an error report from the simulator, and if for some reason the simulation continues the probable eventual de-reference of null will certainly stop things (though, I suppose, one should be careful to make sure that the target variable is null before calling $cast…).
What is in ovm really is best… $cast as a task, when it fails will cause an error report from the simulator, and if for some reason the simulation continues the probable eventual de-reference of null will certainly stop things (though, I suppose, one should be careful to make sure that the target variable is null before calling $cast…).
I hate to kick a dead horse here, but the ovm code may be a very small part of a very large verification project and the ovm code could be from a third party. It would be kind to the user to catch the error and throw a very clear exception as to what happened, who to blame, etc. Also, how good are the line numbers and runtime information if the code is encrypted?
Not quite, $cast is one of those special SV functions that behaves differently if you call it as a function vs a task. Casting to void or using in an assert expression actually prevents it from generating its own error report.
That was the point - the discussion was that the cast couldn’t fail - casting its return to void would indicate that that particular cast would never fail. Though, if it did … :) Anyway, point taken.