Result of Vote on ISAC Issues 1070, 2099, 2119, 2120, 2122

Dear colleagues,

Voting has now closed on this set of ISAC issues. Formally, all were
approved. The votes for all but 2119 were unanimously in favour. For 2119,
there were two negative votes with the comments below. The ISAC policy is to
reconsider an issue where there is significant negative comment. Hence, I
will refer IR2119 back to ISAC for further consideration. The remainder I'll
forward to myself as Accellera LRM-SC Chair for implementation. I will also
post the voting record on the VASG website. Thanks for your participation.

Cheers,

PA
--

Comments on IR2119:

From Jim Lewis:

While this is a bleeding edge issue, I suspect it will become more
contentious in the future as protected types become more widely adopted.  At
one point in time in the Accellera enhancements, I thought that having a
protected type/class in a package was a suggested way to do a static class
member.

Do we need a deferred shared variable declaration whose type is filled in in
the package?


From John Shields:

From information I've seen this is actually common usage. The IR mentions
restrictions on defered constants not causing problem. I think this is an
incorrect comparison because there is no restriction on how the defered
constant is used by other design units.  The restrictions are only on the
use within the package and package body where the deferred constant is
declared.

What I think we want something more like a defered constant.  The ability to
declare the shared variable in the package header but defer its elaboration
until the body of the package is elaborated along with the protected type's
body.

This could either be by haveing some explicit syntax like

package p1 is
   type t1 is protected
      function count return integer ;
  .....
    end protected;

   variable v1: t1 := OPEN; -- can't actually be used in package p1 until
later
   constant c1 :  v1.count;  -- This would be an error
end package

package body p1 is
   type t1 is protected body
    ...
   end protected body t1;

   variable v1: t1; -- actual elaboration can be used in p1 now; end;

Or implicitly if a shared variable of a protected type is declared in the
same scope as the protected type itself, then it is not elaborated until
immediately after the protected type's body is elaborated. Use of the shared
variable would still have the restricts as if it was a defered constant

package p2 is
   type t2 is protected
      function count return integer ;
  .....
    end protected;

   variable v2: t2;  -- Isn't elaborated here because body of t2 is
elaborated yet
   constant c2 :  v2.count;  -- Still an error because v2 has be elaborated
when c2 is elaborated end package

package body p2 is
   type t2 is protected body
    ...
   end protected body t2;
  -- variable v2 is now elaborated here

end;

--
Dr. Peter J. Ashenden         peter@ashenden.com.au
Ashenden Designs Pty. Ltd.    www.ashenden.com.au
PO Box 640                    VoIP: sip://0871270078@sip.internode.on.net
Stirling, SA 5152             Phone: +61 8 7127 0078
Australia                     Mobile: +61 414 70 9106


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.