RE: [vhdl-200x-ft] Implicitly referencing std.textio and library IEEE

Tristan,
Thanks for all your detailed comments. My only commment is on
>I think the user should choose its default packages.

I am OK with the user choosing his default packages for the project in a user defined library, such as work, or some_name_work.
That definition can be declared ONCE for the project (or a library) in a file, which is compiled once. Thereafter, the user need NOT write all these "libray IEEE; use IEEE.whatever.all". If he does write it, it overrides the default -- this needs some work as to what extent this override takes effect (i.e., all the defaults?).
SHould we restrict this global library/package umbrella to just the IEE E packages, or can we include user defined packages?
I am open to this idea, but if there are objections I would not strongly fight it.

My point is that I want to make things easier for the user.
I heard many complaints about this overhead (library and package declarations before many design units), and I would like to see this new VHDL version handle it in one way or another. A single context declaration for the project is OK with me. Another approach would have been to include all these IEEE packages in the language. However, if this committee strongly objects to this integrated idea, which I prefer, I don't care, as long as the users goal to eliminate this multiplicity of declarations is eliminated, as is currently done in other HDL, like VG and SV.
Ben Cohen

In a message dated 12/21/2004 4:24:48 AM Eastern Standard Time, tgingold@free.fr writes:

>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.
>

-- 
-- 
-----------------------------------------------------------------------------
Ben Cohen Trainer, Consultant, Publisher (310) 721-4830 
http://www.vhdlcohen.com/ vhdlcohen@aol.com 
Author of following textbooks: 
* Using PSL/SUGAR for Formal and Dynamic Verification 2nd Edition, 2004 isbn 0-9705394-6-0
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn 0-9705394-2-8 
* Component Design by Example ", 2001 isbn 0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn 0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn 0-7923-8115
------------------------------------------------------------------------------