Re: [sv-ac] Feedback request

Ed and Arturo,
Thanks for your feedback.  I concede that using object of a class instance
that has a null pointer is problematic.  How about limiting the scope of
assertions in classes to just within the class?  Any reference to an object
with a pointer other than "this" shall be illegal.  The following example
demonstrates the concept.  Would this simplifies things a lot?  Would this
limitation be feasible without too many issues?  Here, the assertions would
be active when the class is created, and remain active until it is nulled.
The ony ega references to objects would be those within the class and
subclasses, and the virtual interfaces, which are linked to actual
interfaces just after they are created.

 interface A_if (input logic clk);
     // ...
   clocking driver_cb @ (posedge clk);
     output rst_n, data_in*,* ld, kind_cp;
     input *data_out*;
   endclocking : driver_cb

   modport drvr_if_mp (clocking driver_cb);
 endinterface : A_if

 class A_driver extends uvm_driver #(A_xactn, A_xactn);
   //....
   virtual interface A_if.drvr_if_mp vif;
   *rand bit[3:0] ct; *
   bit a, b, c;
   function new(string name, uvm_component parent);
    //...
   endfunction : new
   `uvm_component_utils_begin(A_driver)
   `uvm_field_object(req, UVM_ALL_ON)
   `uvm_component_utils_end
   task get_and_drive();
   // ..
  * ap_abc: assert property(@(this.vif.driver_cb)*
*     this.vif.driver_cb.ld |=> this.vif.driver_cb.data_out==this.ct);*
   // The foowing may aso be acceptable
   *ap_abc: assert property(@(this.vif.driver_cb)*
*     this.vif.driver_cb.ld |=> this.vif.driver_cb.data_out==ct);*
endclass : A_driver

module forsv_ac;
  A_driver a_dvr1;
  initial begin
    a_drvr1=new(...);
    // assertions for a_dvr1 become active ...
    // ...spme operations with cycles
    a_dvr1=null;
    // assertions for a_dvr1 stop collecting
   end
endmodule

On Mon, Dec 1, 2014 at 5:41 AM, Eduard Cerny <Eduard.Cerny@synopsys.com>
wrote:

>  Hello Ben,
>
>
>
> just a comment regarding
>
> ] If a class object is null, the assertion should be vacuous.
>
> Does that mean that the system would have to keep track of all objects
> that have disappeared since the beginning of simulation to be able to
> indicate “vacuous” ? and maintain counts how many times it was vacuous (the
> clock may not be dead).
>
>
>
> I tend to agree with Arturo.
>
>
>
> Thanks
>
> ed
>
>
>
>
>
>
>
> *From:* owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] *On Behalf Of *Ben
> Cohen
> *Sent:* Sunday, November 30, 2014 8:51 PM
> *To:* Arturo Salz
> *Cc:* Rich, Dave; Korchemny, Dmitry; sv-ac@eda.org
>
> *Subject:* Re: [sv-ac] Feedback request
>
>
>
> 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* <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.