The approval of the merger of P1604 into P1076 is not an approval (or disapproval) of any resolution to specifying what is and is not allowed in the STD and IEEE libraries. Whatever will be proposed in that area by P1604, if it is not merged into P1076, or by P1076, if the merger is approved, will be presented to the membership of the WG for approval/disapproval separate from this vote.
Try to keep the scope of comments on this vote relevant to the scope of the vote itself. Thanks.
-Steve Bailey
> I will positive ballot anything that eliminates the ability
> of vendors
> to legally place non-standard VHDL design units in the IEEE
> library. By
> "legally" I mean both in the standards sense and the US court
> system sense.
>
> When engineers make the decision to move legacy code from
> 1987 -> 1993
> -> 2002 -> 200x they will have issues to contend with. This is a very
> trivial one to fix along the way.
>
> As for the continued promotion of (non)std_logic_arith I believe we
> (vendors and users) should all publically and vociferously commit to
> eliminating the use of this package as soon as possible and migrate
> people to the appropriate IEEE standard. Otherwise, what is
> the point of
> supporting the production of standards?
>
> We can have a healthy (and probably spirted) debate about
> whether it is
> "good practice" to write VHDL using the arithmetic approach found in
> std_logic_unsigned. If the package (and approach) is that useful and
> widespread then why isn't it standardized? Then there would be no
> problem putting it in the IEEE library. I'd like to see you
> persue that
> avenue.
>
> --
> Aspen Logic, Inc.
> By: Tim Davis, President
>
> Jim Lewis wrote:
>
> >
> >> Should the P1604 WG (scope) be merged into P1076?
> >>
> >> 1. __X__ Affirmative (optional comments will be recorded).
> >
> >
> > I agree that this belongs in 1076, however, I will
> > negative ballot any issue here that moves things already
> > in library ieee out of library ieee (ie: std_logic_arith
> > and std_logic_unsigned). Legacy code must
> > stay working without changes to library references.
> >
> > Jim
>
>
Received on Fri Mar 12 09:25:46 2004
This archive was generated by hypermail 2.1.8 : Fri Mar 12 2004 - 09:26:17 PST