Arturo, Please pardon m ignorance on certain aspects of SV, particularly since I am a user, and not a developer; however, I may bring up some ideas, or at least clarifications on the issues, and I thank you for your patience, and for bringing those up. My comments below. On Sun, Nov 30, 2014 at 4:49 PM, Arturo Salz <Arturo.Salz@synopsys.com> wrote: > 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> 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? > [Ben] We have the freedom to define the LRM. Consider the following example : class c; bit x; endclass module m; bit a, b, clk; c c1; initial forever #10 clk=!clk; initial begin #100 c1=new(); #1000 c1=null; #100 c1=new(); end ap_test: assert property(@(posedge clk) a |=> c1.x ); endmodule : m In this example, c1 is created at time 100, and its name is c1 with a link address. The assertion ap_test uses a non-created object from time 0 to time 100; this is because c1 is null during this time. I say, let this assertion be vacuous during that time since it has no meaning during that time period. During time 100 and 1100 the assertion has significance. At time 1100 the result of the assertion is vacuous again, but it restarts having meaning starting from time 1200. Why do have o make it a fatal error? This is an assertion. What I am saying is that any reference to a null object in an assertion causes the assertion to be disabled, It becomes equivalent to: ap_test: assert property(@(posedge clk) disable iff(c1==null) a |=> c1.x ); > > > 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. > [Ben] We can't use the instance name? In the above example, it would be c1. > > > 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. > In http://www.eda-stds.org/svdb/view.php?id=5068 I added the file assertions_in_classes_b .pdf <http://www.eda-stds.org/svdb/file_download.php?file_id=5950&type=bug> There I have an example of an application with clocking blocks and a virtual interface (the example is short, and does not show the link of the actual interface to the virtual interface). What users want are the following. 1) Write concurrent assertions to address class variables and interface variable; the clocking mechanism is the clocking blocks defined in the SV interfaces. Or example: ap_abc: assert property(@(this.vif.driver_cb) t his.vif.A_cb.ld |=> a ##1 ct <= 4'b1100); 2) Places whee this is needed typically in the drivers (maybe to test the values of random variables over many cycles), or in the relationships between class variables and interface variables or scoreboard or monitored results over time. Note that what Dmitry needs at this time is a list of important and nice to have features. I strongly feel that this is an important enhancement to SV. Sure, it needs work. Do I have all the answers? Obviously, far from it. Is there a workable solution? I think that there is. Ben > > > 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.Received on Sun Nov 30 17:51:57 2014
This archive was generated by hypermail 2.1.8 : Sun Nov 30 2014 - 17:52:02 PST