Subject: Re: [vhdl-200x] Implicit conversion, Overloading, & Strong Typin g
From: Evan Lavelle (anti.spam1@dsl.pipex.com)
Date: Wed Dec 24 2003 - 02:02:00 PST
Tim Davis wrote:
> [DISCLAIMER: I voted against this standard]
>
> I **think** what you are saying Bhasker is that 1076.6 established that
> the **synthesis** tool must accept the "type equivalence" of the
> enumerated identifiers {'1', TRUE, 'H'} and {'0',FALSE,'L'}. The type
> equivalence associations only work because the built-in VHDL operations
> based on these types all have "active high" input/output
> interpretations. There is no equivalent in VHDL to the schematic "OR"
> symbol with bubbled inputs -- ie a DeMorgan equiv NAND gate.
>
> However, they fail when you talk about assertion level. '1' is not
> always asserted (active) true which I believe is Andy's point. While it
> is ok for 1076.6 to be narrow minded because of its smaller domain of
> applicability, I don't agree that it is ok for the VHDL language to be
> narrow minded. Hardware is described in many ways and fixing the type
> equivalence to the one above would be bad in my oppinion.
I agree; this seems to me to be a significant weakness of 1076.6. I've
written code that uses booleans, and I do it the same way as I imagine
everyone else does it: you have a physical level outside the chip, you
set the boolean equivalent at the top level of the chip (possibly
inverting the external signal in the process), and you then use the
boolean signal internally.
The only justification I can see for 1076.6 to define '1' as true and
'0' is false is to have a default for users who have forgotten to set
their physical signal levels. Surely it would be equally (or more) valid
for the tool just to give a warning in this case? In any event, this
can't be used a justification for locking VHDL into a 'positive logic'
mindset.
Evan Lavelle
This archive was generated by hypermail 2b28 : Wed Dec 24 2003 - 02:03:27 PST