RE: [sv-ac] Feedback request

Ben,

See my comments inlined below.

                Arturo

From: Ben Cohen [mailto:hdlcohen@gmail.com]
Sent: Sunday, November 30, 2014 11:00 AM
To: Rich, Dave
Cc: Arturo Salz; Korchemny, Dmitry; sv-ac@eda.org
Subject: Re: [sv-ac] Feedback request

See embedded comments

On Sun, Nov 30, 2014 at 9:20 AM, Rich, Dave <Dave_Rich@mentor.com<mailto:Dave_Rich@mentor.com>> wrote:
Persistence of the class containing the concurrent assertion is only the tip of the iceberg.

There’s also the persistence of the objects being referenced by the assertion, along with their sampling semantics. An assertion inside a class is likely going to want to have properties that reference transaction class objects that may not exist at the time the assertion begins its initial attempt.
​​[Ben] If a class object is null, the assertion should be vacuous.

[Arturo] I believe Dave was also referring to the start time of the assertion. If the assertion refers to dynamic objects that are yet to be created, that is currently an fatal error. It seems inconsistent to just say the assertion is vacuous. What about preconditions?

Functional coverage of embedded concurrent assertions is another issue that closely resembles an embedded covergroup in a class. Do you collect statistics merged as a single class type (any non-vacuous pass in a single class instance means the assertion passes), or do you treat all class instances independently (All instances of a class type must have non-vacuous passes to consider the assertion passing)?
​[Ben] Can they be treated in a manner similar to concurrent assertions in a module that is instantiated multiple times?  Thus, each instance of a class will maintain its own statistics on the assertions and coverage. This is necessary anyway since separate instances of a class type may have different interfaces (e.g., driver1.vif maybe connected to if1, and ​

​
 driver
​2​
.vif maybe connected to if
​2; driver1 and driver2 are instances of driver class type).

​[Arturo] I don’t believe that is practical. There is no naming mechanism in the language to distinguish object of the same type. Module instances have structural hierarchy and the names of each instance is both bounded and well-defined. Object instances are both unbounded and have no specific name.

And then there are procedural concurrent assertions in classes.
​[Ben] Can those be treated in the same manner we treat procedural concurrent assertions in always blocks? ​


I’m bring all this up not to say that it can’t be done, but that it is a major project that practically needs a separate group to deal with all the interactions between the different concepts.
​[Ben] Agree.  However, the user community seems to want this feature of adding assertions in classes.
​
 ​[Arturo] I am not sure what it is that he user community seems to want. Is it the ability to add assertions in classes just because classes seem convenient scopes? Or, is it declaring assertions that operate on object members and other dynamic objects? Generally, the notion of concurrent (clocked) assertions and generic software objects (class instances) seems to me to be somewhat incongruous. Unclocked software invariants are a completely different story – not all wheels fit all vehicles.

Dave


From: owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org> [mailto:owner-sv-ac@eda.org<mailto:owner-sv-ac@eda.org>] On Behalf Of Ben Cohen
Sent: Friday, November 28, 2014 7:37 PM
To: Arturo Salz
Cc: Korchemny, Dmitry; sv-ac@eda.org<mailto:sv-ac@eda.org>
Subject: Re: [sv-ac] Feedback request

[Arturo] ... class containing concurrent assertions will likely become persistent
[Ben] From a user point of view, I would like to see a solution that is relatively easy to implement so that vendor support this class feature expediently.
In UVM, VMM, or even typical non-library based approach, once a class instance is created (i.e., with the new or UVM create) they tend to be persistent and are never nulled.  These classes include the driver, monitor, scoreboard, environment, agent).
Thus, if adoption of this proposal can  be simplified by putting some restrictions on the lifetime of created class instance, I am all for it.  Those of you who understand implementation can provide some useful insights as to what is needed.
Ben

On Fri, Nov 28, 2014 at 7:02 PM, Arturo Salz <Arturo.Salz@synopsys.com<mailto:Arturo.Salz@synopsys.com>> wrote:
I’d like to provide some feedback on:
  5068: concurrent assertions in classes

This enhancement seems like a good addition to the language, however, it introduces a difficulty regarding reclamation of classes. Since concurrent assertions do not have a lifetime, a class containing concurrent assertions will likely become persistent. This may be OK for certain uses, but I wanted to point that out. Either the rules for assertion lifetime are enhanced (e.e., allow users to destroy an assertion) or else document the potential memory leak in the LRM.

                Arturo

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.