Re: [sv-ac] Feedback request

See embedded comments

On Sun, Nov 30, 2014 at 9:20 AM, Rich, Dave <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.

>
>
> 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).
​

>
>
> 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. ​


>
>
> Dave
>
>
>
>
>
> *From:* 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
> *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>
> 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.