Selon VhdlCohen@aol.com:
> Steve Bailey said it best:
> <Let's not all forget the context:>
> Ben: Back then, the guarded blocks were not popular, and 1164 came into
> being, and was popular. Making 1164 and textio part of "the core" does not
> add any extra baggage because those types and methods will be introduced by
> the compiler only when needed.
> Note that package "standard" is part of the core, and it is not necessary to
> add at the front of every entity or package declaration "library std; use
> std.standard.all;". So why not integrate the 1164 and textio, and even the
> floating point packages as part of the core?
You can't work without standard. It is very special.
Now, if you start to 'integrate' packages, the list can be very very long,
and package integration battles will start.
> <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.>
>
> Ben: I did not follow the idea of "context", but it sounds similar to a
> Verilog "include".
> If it is a defaulted context, then I'll buy it.
>
> <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.>
> Great if 1164, textio, and floating point packages can be the defaults.
I think the user should choose its default packages.
> > 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.
> No war here. But many successful designs were implemented in both HDLs.
> Linting tools, for both HDLs have helped iron out coding errors.
> BTW, SystemVerilog has introduced several types that are in VHDL (e.g., enu,
> structure, multi-dimensional arrays) + classes. My point in mentioning
> Verilog was that the core included everything, and users do not need to
> import packages to access things that are defined in the LRM.
>
> >
> > VHDL:
> > * a core: 1076
> > * additionnal packages: 1164, 1076.x
> Thus, you are saying that the additional packages are part of the LRM, but
> not part of the core. I don't like that!
For me that's the base of structured language design.
> > 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.
> Separating the core from additional packages does not ease the situation!
It does.
Once you understand the core (which is easier when the core is small), you
can understand additional packages one after the other.
Furthermore, how do you know wether the core is coherent or not ?
According to the history, the VHDL core is already too big: there were many
errors (and not only bugs/typos) in the LRM.
However, it is possible to write a VHDL tool only with the LRM.
For Verilog, you can't. So many areas are undefined. In fact, Verilog is
defined by the verilog LRM and by Verilog-XL (tm/c).
> > Furthermore, not everyone want to use ieee.std_logic_1164.
> > Think about people who just use bit/bit_vector, or AMS-VHDL.
> Bits are are in the core.
They shouldn't. Maybe they could be moved into a std.std_bit package.
BIT is almost a regular type.
[...]
> > 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.
>
> I use emacs, a great vhdl editor! But that is not the issue.
That's an issue. You were speaking about typing. A good editor can change
your productivity.
> The core in
> any language should include the complete dictionary of what users need.
> VHDL is mature enough by now, and we know what engineers are currently
> using.
Yes, but we don't know the future or other usage of VHDL.
> By the way, 1076.6 IEEE Standard for VHDL Register Transfer Level (RTL)
> Synthesis
> is used in conjunction with IEEE Std 1076.3TM-1997, IEEE Standard Synthesis
> Packages (NUMERIC_BIT and NUMERIC_STD), which should be part of the core.
These packages were created and standardized without modifying the VHDL 1076
LRM. This is flexible, and IMHO was good.
Tristan.
Received on Tue Dec 21 01:24:54 2004
This archive was generated by hypermail 2.1.8 : Tue Dec 21 2004 - 01:24:56 PST