[*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, and is believed to be clean.Received on Fri Nov 28 19:38:15 2014
This archive was generated by hypermail 2.1.8 : Fri Nov 28 2014 - 19:38:24 PST