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

Selon "Bailey, Stephen" <SBailey@model.com>:

> 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.
I don't fully agree.
bit+guard+register+bus don't allow you to model strength, uninitialized
or conflicts.

BTW, it is maybe time to deprecate guard/register/bus/disconnection ?

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

> 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.
IMHO, the important point is that VHDL was complete enough to allow the user
to define its own logic type.

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

> 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.
Here is my contribution: every design unit (except itself) use the context
'DEFAULT' of its
library, if it exists ?
I don't really like such mecanim: if the 'DEFAULT' context unit is missing,
the analyze fails without any clear message.

> (Also, I would point out that the context unit also softens any
> difference between including IO routines in the base package or separate
> package.)
For me, that's a reason why they should be in separate packages.

Tristan.
Received on Tue Dec 21 01:05:38 2004