Date: Fri Apr 01 2011 - 14:10:24 PDT
OK, I will revise this proposal to make sure it only removes the restrictions on NBA. An NBA is a procedural construct. That would leave automatic variables as the only restriction on the target of NBAs. References to targets of NBAs are kept alive same as if passed by reference to a task inside a fork/join_none block.
Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[Description: Twitter-32]<http://www.twitter.com/dave_59> [Description: Technorati-32] <http://go.mentor.com/drich>
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Tuesday, March 29, 2011 2:16 PM
To: Rich, Dave; sv-ec@eda.org
Subject: RE: New proposal for 2112 Remove restrictions on NBA assignments to class members
________________________________
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Tuesday, March 29, 2011 3:18 AM
To: Steven Sharp; sv-ec@eda.org
Subject: RE: New proposal for 2112 Remove restrictions on NBA assignments to class members
Hi Steven,
My intent was to keep the rules as simple as possible. The LRM already allows
always @(classA_h.m1) classB_h.m2 = classA_h.m1;
leaving it up to the user to prevent null handle references. So why not allow
assign classB_h.m2 = classA_h.m1;
leaving it up to the user to prevent the same null references. I gave an example using a static initialization to prevent a null reference in my proposal.
There are differences between these two things. I don't think the static initializer in your example is guaranteed to prevent a null references. The LRM specifies that initializers execute before always blocks, but I don't think it says that they execute before continuous assignments evaluate at time zero. Your example seems to recognize this, since you guarded the reference with a check for a null handle. You cannot do an equivalent guard on the LHS.
The LRM also has rules about single drivers with continuous assignments. You can only have a single driver for a given longest static prefix. In this case, the closest equivalent to a longest static prefix is empty. It doesn't even contain classB_h, since classB_h.m2 and classB_h2.m2 could refer to the same thing, even though the handle variable is different. Since the static prefix is empty, it technically conflicts with any other continuous assignment to a variable in the design. You could add rules to the longest static prefix rule that tried to restrict it based on type, i.e. you know classB_h refers to an object of classB type and can't conflict with an assignment to anything else. But there is no such type-based rule in the current LRM. And that would still leave you unable to have two continuous assignments to different classB objects because they might refer to the same object, rendering these continuous assignments almost useless.
This single-driver rule doesn't apply to the procedural assignment in the combinational always block.
There may be other issues as well. And then there are a bunch of issues with procedural continuous assignments.
Restricting this to NBAs is keeping the rules as simple as possible.
We have related issue in that most implementations already allow these kinds of illegal assignments with virtual interface members, even though it's referencing a dynamic variable. See related http://www.eda.org/svdb/view.php?id=1441
The problem here is that the rule is specified in terms of whether the variable is dynamic, but some of the problems are related to the fact that the reference mechanism is dynamic (i.e. you can change the object that is being referenced by the lvalue at runtime). Most of the dynamic reference mechanisms, such as class handles, refer to dynamic objects, so the restriction is adequate. But virtual interfaces are a dynamic mechanism for referencing static objects. So the rule didn't address them as it should have.
If the rules are clear to the user and mistakes are clear to the user (error: NULL de-reference!), then I think it's worth specifying it this way.
I think you are missing a lot of the problems involved here.
Dave Rich
Verification Technologist
Mentor Graphics Corporation
[Description: Twitter-32]<http://www.twitter.com/dave_59>[Description: Technorati-32]<http://go.mentor.com/drich>
From: Steven Sharp [mailto:sharp@cadence.com]
Sent: Monday, March 28, 2011 11:12 PM
To: Rich, Dave; sv-ec@eda.org
Subject: RE: New proposal for 2112 Remove restrictions on NBA assignments to class members
Dave,
Your first change in 6.21 would allow class members to be assigned with not only NBAs, but also continuous assignments and procedural continuous assignments. I don't think this was your intent, and there would be problems with that. For example, continuous assignments could have the same problem you describe later for the class member on the RHS of a continuous assignment, but without any way of avoiding the possible null handle dereference.
I think you will either need to split out a sentence which describes the limits for NBAs separately from the ones for the other assignments, or leave the original sentence that disallows all combinations, but then specifically says that NBAs to class members are an exception that are allowed.
________________________________
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Rich, Dave
Sent: Monday, March 28, 2011 1:57 AM
To: sv-ec@eda.org
Subject: [sv-ec] New proposal for 2112 Remove restrictions on NBA assignments to class members
I have uploaded a proposal for 2112. The only actual change is the relaxation of the restriction in 6.21. The other edits are suggested clarifications as we discussed in earlier sv-bc meetings.
Dave Rich
Verification Technologist
Mentor Graphics Corporation
New Office Number: 510-354-7439
[Description: Twitter-32]<http://www.twitter.com/dave_59>[Description: Technorati-32]<http://go.mentor.com/drich>
-- 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.
