[vhdl-200x] Re: Result of Vote on ISAC Issues 1070, 2099, 2119, 2120, 2122

Peter Ashenden wrote:
> 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
>
>
>   
Since IR 2119 is an enhancement request, I believe that we can move 
forward with the revisions to the Accellera document.
In parallel, the ISAC can review 2119 and pass comments on to the 
requirements committee.

What do the rest of you think?

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