Let's not all forget the context:
1. VHDL did collect a number of basic types in std.standard package.
The original language design did not include std_logic because there
were mechanisms built into the language to turn-off drivers, etc. So
while the original language design was general enough to allow any logic
type to be defined (and several non-standard ones were), a case can be
made that the original designers believed the language, including
std.standard, included everything that was needed to do RTL design.
2. Usage and pre-existing convention indicated that disconnection
specifications, guarded blocks, etc. were not how people wanted to model
at the RTL (let only gate). The key indicator being the proliferation
of various logic types and the adoption of them by users. So,
std_logic_1164 came into being.
3. Probably for reasons of convenience as much as for any other
well-thought out reasons, the std_logic types and operations were
defined in a separate package in a separate library. This made sense
within the context of testing and verifying the implementation.
However, the need for the package was so strong, people were heavily
using it before it became an official standard. It became difficult to
move it. (And, it wasn't the most important thing to be worried about.
4. Currently, there's no significant driving force that would require
us to break backward compatibility. The main benefit in moving is
convenience. Personally, I do not downplay this benefit. However, I
believe Jim has come up with an elegant and more general mechanism for
addressing the convenience issue: context units.
5. With context units, the most a user must do is explicitly reference
the context unit to get the library and use clauses for all that they
need. It was also my desire to see the LRM allow tools a mechanism by
which the specification of a default context clause could be specified
and automatically applied just ast library STD and use STD.STANDARD.all
are implicit today.
In summary, I believe if we are to address the convenience benefit, we
should do so via context units and an ability to specify a default
context unit. This will ensure backward compatibility with all existing
VHDL code.
(Also, I would point out that the context unit also softens any
difference between including IO routines in the base package or separate
package.)
-Steve Bailey
> -----Original Message-----
> From: owner-vhdl-200x-ft@eda.org
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of tgingold@free.fr
> Sent: Monday, December 20, 2004 3:23 AM
> To: VhdlCohen@aol.com
> Cc: Jim Lewis; vhdl-200x-ft@eda.org
> Subject: Re: [vhdl-200x-ft] Implicitly referencing std.textio
> and library IEEE
>
> Selon VhdlCohen@aol.com:
>
> > Unless the packages conflict with each other, I am in favor of
> > integrating the packages as part of VHDL, and eliminate the need to
> > separately identify which package I need.
> > This is done in Verilog and SystemVerilog. SV has integrated new
> > system functions and methods, but they are all part of the
> language.
> > You don't import packages that are part of the language!
> > In my mind, a package is a library, which is only make
> accessible when used.
> > I still remember the posting in comp.lang.vhdl where a user felt
> > relief when switching to VG because he longer had to type
> the "library
> > IEEE; use IEEE.std_1164.all".
> > From my perpective, why force the user to get down to those
> levels of
> > details when the types and methods described in those
> packages are standards.
> > Ben Cohen
> I really understand this point of view.
> However, this point of view break the VHDL spirit.
> VHDL and Verilog are two opposites way to handle features:
>
> Verilog:
> * a bag of anything (unless I am wrong); no real structure.
>
> VHDL:
> * a core: 1076
> * additionnal packages: 1164, 1076.x
> Each time you want to use an additionnal package, you have to
> say it explicitly.
> VHDL shares this structured way with many many languages: C,
> C++, java...
>
> Each time a feature has to be added in Verilog, it is added
> in the core.
> Therefore the core is huge and difficult to read.
>
> Currently, with VHDL, just understand the core, and write
> additionnal features in VHDL. This can't be done in verilog,
> since the core is not yet powerful enough.
>
> Furthermore, not everyone want to use ieee.std_logic_1164.
> Think about people who just use bit/bit_vector, or AMS-VHDL.
>
>
> For your user on comp.lang.vhdl, I have two comments:
> * He should use a good editor/IDE, which may automatically
> add the context clauses.
> * He surely doesn't understand VHDL beyond basic feature, and
> in this case, Verilog may be better for him.
>
> Tristan.
>
Received on Mon Dec 20 07:04:58 2004
This archive was generated by hypermail 2.1.8 : Mon Dec 20 2004 - 07:05:01 PST