News on VHDL-200X

Discussion in 'VHDL' started by Rick North, Oct 31, 2006.

  1. Rick North

    Rick North Guest

    Hi,

    Does anybody have any news regarding the ongoing work on VHDL?

    The reason for asking is that there is a great pull towards
    SystemVerilog at my company. The main arguments are the verification
    features which SV has such as constrained
    random, coverage, interfaces etc. On the other hand for a design view
    point the floating package is a great plus for VHDL and all the legacy
    code that has been developed over the years inside the company.

    Does anybody has a feel of when vhdl has reached (or surpassed)
    SystemVerilog and when the tools are ready for the new VHDL standard?
    Is it 5 years from now, then I might have to give up and join the
    SystemVerilog mob which seems to be most happy with SV and all the
    bells and whistles.

    Cheers,
    /the VHDL gimp
     
    Rick North, Oct 31, 2006
    #1
    1. Advertising

  2. Rick North

    Jim Lewis Guest

    Rick,
    The Accellera VHDL TSC has taken over the VHDL-200X effort.
    Its first revision, Accellera VHDL-2006 standard 3.0, was
    approved at DAC and is available for adoption (vendors first
    of course). My understanding is that simulation vendors are
    currently working on these additions now.

    The primary verification features added in this revision
    are direct integration of PSL, generics on packages and type
    generics. The generics on packages and type generics give
    us the capability to build verification data structures in
    standard packages. I have posted a papers on the current
    revision under the title Accellera VHDL 2006 Standard 3.0 at:
    http://www.synthworks.com/papers/index.htm

    If you like what you see, make sure your vendor knows that
    you want the features. In addition, make sure they know
    which features are most important to you - like everything
    else these are often implemented in a priority fashion.

    For the next revision, good progress has been made on
    constrained random and interface features. My guess is that
    we will have this for DAC 2007.

    If you want to keep a pulse on things, join the Accellera
    VHDL TSC and the VHDL Extensions subgroup. Neither of these
    require a paid Accellera membership. By joining you are also
    expressing your interest in VHDL standards which acts as a
    motivator for EDA vendors to implement the standards.
    Of course for those of you that belong to larger organizations
    your membership fees go to help fund the standards.
    For Accellera VHDL TSC membership, goto:
    http://www.accellera.org/activities/vhdl


    Cheers,
    Jim Lewis
    VHDL Standards Advocate
    Participant in both Accellera and IEEE VHDL standardization efforts.
    IEEE VHDL/VASG chair http://www.eda.org/vasg

    P.S.
    Everything Accellera standardizes will eventually become an
    IEEE standard - it is just faster to do it in Accellera first.




    > Hi,
    >
    > Does anybody have any news regarding the ongoing work on VHDL?
    >
    > The reason for asking is that there is a great pull towards
    > SystemVerilog at my company. The main arguments are the verification
    > features which SV has such as constrained
    > random, coverage, interfaces etc. On the other hand for a design view
    > point the floating package is a great plus for VHDL and all the legacy
    > code that has been developed over the years inside the company.
    >
    > Does anybody has a feel of when vhdl has reached (or surpassed)
    > SystemVerilog and when the tools are ready for the new VHDL standard?
    > Is it 5 years from now, then I might have to give up and join the
    > SystemVerilog mob which seems to be most happy with SV and all the
    > bells and whistles.
    >
    > Cheers,
    > /the VHDL gimp
    >



    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Oct 31, 2006
    #2
    1. Advertising

  3. Rick North wrote:

    > The reason for asking is that there is a great pull towards
    > SystemVerilog at my company. The main arguments are the verification
    > features which SV has such as constrained
    > random, coverage, interfaces etc.


    I would hang fire until I saw a working
    example on a real design.


    > On the other hand for a design view
    > point the floating package is a great plus for VHDL and all the legacy
    > code that has been developed over the years inside the company.


    You're preaching to the choir.

    > Does anybody has a feel of when vhdl has reached (or surpassed)
    > SystemVerilog and when the tools are ready for the new VHDL standard?
    > Is it 5 years from now, then I might have to give up and join the
    > SystemVerilog mob which seems to be most happy with SV and all the
    > bells and whistles.


    If my FPGA tool process were stymied for lack of
    constrained random variation, I might take a look.
    Until then, I wait until someone in the mob completes
    a project.

    -- Mike Treseler
     
    Mike Treseler, Oct 31, 2006
    #3
  4. Rick North wrote:
    > The reason for asking is that there is a great pull towards
    > SystemVerilog at my company. The main arguments are the verification
    > features which SV has such as constrained
    > random, coverage, interfaces etc. On the other hand for a design view
    > point the floating package is a great plus for VHDL and all the legacy
    > code that has been developed over the years inside the company.


    Have you tought about mixed view, all major simulators support it well.
    Do the testbench in SV and design in VHDL. That might combine the good
    features from both languages. At least in my opinion that might be
    good approach in future.

    Of course the mixed view can cause some problems is you have complex data
    types in the interfaces of blocks that you want to observe. But that might
    be a problem for synthesis also (some tools are not so good with records in
    ports etc.). So it is a question of legacy vs. new code, and for example is
    the legacy code more in RTL or TB side.

    I have already given up with VHDL in testbenches, it is so much easier to
    code them for example with Vera (which is quite near SV). On the other
    hand in my opinion VHDL is good language for the RTL design, because of
    strong typing and some other features.

    --Kim
     
    Kim Enkovaara, Nov 1, 2006
    #4
  5. Rick North

    Ajeetha Guest

    Hi Mike,

    > I would hang fire until I saw a working
    > example on a real design.
    >
    >


    I guess it depends on how you define a "real life design", for
    instance, see:

    http://www.accellera.org/activities/date_presentations_06/NSC_DATE_2006.pdf

    There are several other papers/press releases in verificationguild.com,
    vendors' web sites etc. The vendors' web site I would be little
    hesitant to fully trust, but it can't be 100% false information
    (hopefully).

    Also the concepts of coverage, constraints have been used with Specman,
    Vera etc. for 5+ years now (actually may be even a decade), and with SV
    things are becoming mainstream.

    Having said all this, I'm all for VHDL for design and SV for testbench
    9as Kim mentioned), I see lot of local companies moving in that
    direction here - atleast ASIC houses.

    Is there any standard defining Mixed language syntax/semantics between
    Verilog & VHDL - AFAIK it is all by implementation and though major
    vendors support the basic Verilog-VHDL, starting V2K, SV etc. things
    are more complicated IMHO.

    Regards
    Ajeetha, CVC
    www.noveldv.com
     
    Ajeetha, Nov 1, 2006
    #5
  6. Rick North

    Guest

    Hi Jim,

    this looks very impressive!! I usually avoid IEEE/Accellera documents
    because they are next to unreadable to me, but your summary at

    http://www.synthworks.com/papers/vhdl_accellera_lewis_marlug_2006_color.pdf

    looks really good. I advice _everybody_ on the newsgroup to check it
    out.



    After that, please give your EDA vendors a call :)



    once again, nice job Accellera!
    burns


    Jim Lewis wrote:
    > Rick,
    > The Accellera VHDL TSC has taken over the VHDL-200X effort.
    > Its first revision, Accellera VHDL-2006 standard 3.0, was
    > approved at DAC and is available for adoption (vendors first
    > of course). My understanding is that simulation vendors are
    > currently working on these additions now.
    >
    > The primary verification features added in this revision
    > are direct integration of PSL, generics on packages and type
    > generics. The generics on packages and type generics give
    > us the capability to build verification data structures in
    > standard packages. I have posted a papers on the current
    > revision under the title Accellera VHDL 2006 Standard 3.0 at:
    > http://www.synthworks.com/papers/index.htm
    >
    > If you like what you see, make sure your vendor knows that
    > you want the features. In addition, make sure they know
    > which features are most important to you - like everything
    > else these are often implemented in a priority fashion.
    >
    > For the next revision, good progress has been made on
    > constrained random and interface features. My guess is that
    > we will have this for DAC 2007.
    >
    > If you want to keep a pulse on things, join the Accellera
    > VHDL TSC and the VHDL Extensions subgroup. Neither of these
    > require a paid Accellera membership. By joining you are also
    > expressing your interest in VHDL standards which acts as a
    > motivator for EDA vendors to implement the standards.
    > Of course for those of you that belong to larger organizations
    > your membership fees go to help fund the standards.
    > For Accellera VHDL TSC membership, goto:
    > http://www.accellera.org/activities/vhdl
    >
    >
    > Cheers,
    > Jim Lewis
    > VHDL Standards Advocate
    > Participant in both Accellera and IEEE VHDL standardization efforts.
    > IEEE VHDL/VASG chair http://www.eda.org/vasg
    >
    > P.S.
    > Everything Accellera standardizes will eventually become an
    > IEEE standard - it is just faster to do it in Accellera first.
    >
    >
     
    , Nov 1, 2006
    #6
  7. Rick North

    Evan Lavelle Guest

    On Tue, 31 Oct 2006 15:28:19 -0800, Jim Lewis <>
    wrote:

    >I have posted a papers on the current
    >revision under the title Accellera VHDL 2006 Standard 3.0 at:
    > http://www.synthworks.com/papers/index.htm


    A nice presentation; a couple of quick thoughts:

    p6 - I can't believe it took 15-odd years to get a standard VHPI and
    another 5 to formalise it. For my money, this is the one thing that
    has done most to hold back VHDL over the years.

    p11 - is the constant initialiser correct? It seems to have too many
    bits

    p12 - Would it be more usal to call the 'fraction' of a floating-point
    type a 'significand'?

    p13 - <pedantic> s/heirarchy/hierarchy/ </pedantic>

    pp17/18 - is the only relaxation of the locally and globally static
    rules (and p24)? If so, this seems to be an opportunity lost. Many of
    the rules are pointless, and exist because of limited compilation
    computing power in the early 80's.

    p20 - presumably allowing if(cs) instead of if(cs = '1') was to handle
    PSL conditionals? Have you relaxed the typing rules just in this one
    case (and p29)? If so, does it really make sense to break the existing
    typing rules just for this one ad-hoc exception? (And don't all those
    brackets make it look rather C-like? :))

    p24 - signal expressions in port maps - "needed to avoid extra signal
    assignments with OVL"?! Seriously? We've had to put up with globally
    static expressions in port maps for all these years and finally,
    you've relaxed it for *Accellera OVL*??

    p25 - reading output ports - this has been on the cards for years. It
    seems a bit contentious to justify it because assertions needed this
    feature; the rest of us needed it long before assertions did.

    p26 - "allow conditional assignments for signals and variables in
    sequential code". A useful addition to clean up some verbosity? Or
    just two ways to do exactly the same thing because the first way was
    too verbose? Basic tenet of language design: don't give users multiple
    ways to do the same thing. In particular, don't wait 20+ years then do
    a partial syntactic up-sugaring exercise. If you wanted to fix the
    syntax, you should have done it properly, or not at all. Sorry.... :)

    p27 - allowing selected assignments in sequential code - ditto; even
    more so.

    p28 - unary reduction operators. I've got a bad feeling about this.
    Doesn't it cause confusion in Verilog code? Which is better - "a <=
    xor b xor c", or "a <= xor_reduce(b) xor c"?

    p29 - array/scalar logic operators; so we can now have built-in
    overloading to, for example, AND a std_logic with a SLV4. We can
    already do this without a built-in; so what's the point? VHDL is meant
    to be strongly typed. Is VHDL-200x also meant to be strongly typed, or
    not?

    p30 - <pedantic, etc> "data read back logic" - typo?

    p36 - very confusing; you need to read p37 in detail to understand it.
    Even then, it's still confusing - what's the "Logic, Addition" row?
    Are any of these rows meant to cover exisiting vendor-specific
    std_logic_unsigneds? They don't seem to.

    p38 - just my personal opinion, of course - HDLs and 'programming'
    languages are *very* different. The two common HDLs are 80's dinosaurs
    that can't be fixed; one of them wasn't designed, and the other was
    designed by a committee. What's the point of trying to shoe-horn
    'real' language features like constrained random generation and all
    the rest of it into Verilog or VHDL? They're intended for something
    completely different, and they're totally unable to take this extra
    infrastructure. There is no point, and it makes no sense whatever,
    except for the EDA vendors. If you want the extras, you can already
    buy them in appropriate languages that were designed for the job.

    p40 - s#"E (specman)"#'e'/Specman#

    Have any vendors shown any interest in actually implementing
    "Accellera VHDL-2006"?

    >P.S.
    >Everything Accellera standardizes will eventually become an
    >IEEE standard - it is just faster to do it in Accellera first.


    If any single statement could encapsulate why the IEEE is totally
    irrelevant in language standardisation, this is it. Why doesn't
    Accellera have the balls to issue its own standards, instead of
    pretending that they're independent IEEE standards? They're not; I
    think most people appreciate this now.

    Evan
     
    Evan Lavelle, Nov 3, 2006
    #7
  8. Rick North

    Ben Jones Guest

    "Evan Lavelle" <> wrote in message
    news:...
    > On Tue, 31 Oct 2006 15:28:19 -0800, Jim Lewis <>
    > wrote:
    >
    > p12 - Would it be more usal to call the 'fraction' of a floating-point
    > type a 'significand'?


    Actually no, they are different. The significand is similar to the fraction,
    but it includes the implicit "hidden" 1 bit in front of the binary point.

    Cheers,

    -Ben-
     
    Ben Jones, Nov 3, 2006
    #8
  9. Rick North

    Jim Lewis Guest

    Evan,
    > p11 - is the constant initialiser correct? It seems to have too many
    > bits

    OOPS. Thanks.

    > pp17/18 - is the only relaxation of the locally and globally static
    > rules (and p24)? If so, this seems to be an opportunity lost. Many of
    > the rules are pointless, and exist because of limited compilation
    > computing power in the early 80's.


    Consider it a start.

    > p20 - presumably allowing if(cs) instead of if(cs = '1') was to handle
    > PSL conditionals? Have you relaxed the typing rules just in this one
    > case (and p29)? If so, does it really make sense to break the existing
    > typing rules just for this one ad-hoc exception? (And don't all those
    > brackets make it look rather C-like? :))

    It is more like adding overloading to conditionals.

    The more I look at this the more I am convinced that
    an HDL never should have had type boolean. Hind sight.

    > p24 - signal expressions in port maps -
    > p25 - reading output ports -

    Long time coming.

    > p26 - "allow conditional assignments for signals and variables in
    > sequential code". A useful addition to clean up some verbosity? Or
    > just two ways to do exactly the same thing because the first way was
    > too verbose? Basic tenet of language design: don't give users multiple
    > ways to do the same thing. In particular, don't wait 20+ years then do
    > a partial syntactic up-sugaring exercise. If you wanted to fix the
    > syntax, you should have done it properly, or not at all. Sorry.... :)
    >
    > p27 - allowing selected assignments in sequential code - ditto; even
    > more so.

    From a uniformity perspective, these statements can now be used in
    both concurrent and sequential code. Uniformity is good.

    >
    > p28 - unary reduction operators. I've got a bad feeling about this.
    > Doesn't it cause confusion in Verilog code? Which is better - "a <=
    > xor b xor c", or "a <= xor_reduce(b) xor c"?


    Correcting your assignment: a <= (xor b) xor c ;
    When a unary reduction operator is used in an expression,
    parentheses are required.

    > p29 - array/scalar logic operators; so we can now have built-in
    > overloading to, for example, AND a std_logic with a SLV4. We can
    > already do this without a built-in; so what's the point? VHDL is meant
    > to be strongly typed. Is VHDL-200x also meant to be strongly typed, or
    > not?

    Can but unfortunately some synthesis tools don't support it,
    so hardware designers need something we can use.

    > p36 - very confusing; you need to read p37 in detail to understand it.
    > Even then, it's still confusing - what's the "Logic, Addition" row?

    Overloading that is common to both Logic and Addition operators.
    Operator naming per 1076.

    > Are any of these rows meant to cover exisiting vendor-specific
    > std_logic_unsigneds? They don't seem to.


    No. Operators in std_logic_arith and std_logic_unsigned will
    not be locally static. Very compelling reason to switch for
    those who have not.

    > p38 - just my personal opinion, of course - HDLs and 'programming'
    > languages are *very* different. The two common HDLs are 80's dinosaurs
    > that can't be fixed; one of them wasn't designed, and the other was
    > designed by a committee. What's the point of trying to shoe-horn
    > 'real' language features like constrained random generation and all
    > the rest of it into Verilog or VHDL? They're intended for something
    > completely different, and they're totally unable to take this extra
    > infrastructure. There is no point, and it makes no sense whatever,
    > except for the EDA vendors. If you want the extras, you can already
    > buy them in appropriate languages that were designed for the job.


    Looking at SystemVerilog, I see where you are coming from, however,
    perhaps you should hold your judgement on VHDL until we finish.
    Something with familiar syntax is much better than something
    with new syntax and has no formal way to be mixed together.

    > Have any vendors shown any interest in actually implementing
    > "Accellera VHDL-2006"?

    The ones I have talked to are actively working on it.


    >> Everything Accellera standardizes will eventually become an
    >> IEEE standard - it is just faster to do it in Accellera first.

    >
    > If any single statement could encapsulate why the IEEE is totally
    > irrelevant in language standardisation, this is it. Why doesn't
    > Accellera have the balls to issue its own standards, instead of
    > pretending that they're independent IEEE standards? They're not; I
    > think most people appreciate this now.


    From a standards perspective, we made good progress under IEEE,
    however, IEEE did not have infrastructure to fund the effort.
    Now with CAG, perhaps there is a way to do it all under IEEE.
    Time will tell. I don't expect to explore this option though
    unless we have a compelling reason to do so.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 3, 2006
    #9
  10. Rick North

    Evan Lavelle Guest

    On Fri, 03 Nov 2006 08:49:56 -0800, Jim Lewis <>
    wrote:

    >> p20 - presumably allowing if(cs) instead of if(cs = '1') was to handle
    >> PSL conditionals? Have you relaxed the typing rules just in this one
    >> case (and p29)? If so, does it really make sense to break the existing
    >> typing rules just for this one ad-hoc exception? (And don't all those
    >> brackets make it look rather C-like? :))

    >It is more like adding overloading to conditionals.


    I would feel better about this if you could point to any other
    languages that do this; I don't understand the concept of 'overloading
    a conditional'. How could a conditional decide that an arbitrary
    (non-boolean) enumeration literal is somehow equal to a different
    (boolean) enumeration literal? Can I make my own enumerated types when
    one or more literals is also implicitly equal to true? I'm sorry, but
    I can't see that this makes any sense at all; a character enumeration
    literal, such as '1', has no special significance other than to a
    synthesiser.

    You could try to make the case that you're actually overloading the
    equality operator in some implicit fashion. But, of course, you'd then
    have to deal with scope/visibility/implict/explicit/etc. issues.

    There is a solution which works: introduce a new data type, which has
    the 4 values 0, 1, x and z (ie. *not* enumeration literals). This has
    several benefits: it fixes the conditional problem, reduces verbosity,
    allows Verilog compatibility, gives you your casex/etc. without new
    kludges, might even give you faster simulation, and so on. It would be
    interesting to know why this wasn't considered.

    >The more I look at this the more I am convinced that
    >an HDL never should have had type boolean. Hind sight.


    Maybe, but only if you've got a basic type which can be used directly
    in conditionals. We don't, and this proposal doesn't give one; it's
    just a nasty kludge.

    >> p28 - unary reduction operators. I've got a bad feeling about this.
    >> Doesn't it cause confusion in Verilog code? Which is better - "a <=
    >> xor b xor c", or "a <= xor_reduce(b) xor c"?

    >
    >Correcting your assignment: a <= (xor b) xor c ;
    >When a unary reduction operator is used in an expression,
    >parentheses are required.


    But the analyser doesn't need parentheses, so this is just *required*
    syntactic sugar. Any what about "a <= xor b"? Is this a syntax error?
    Does it have to be "a <= (xor b)"? You appear to be suggesting that
    the analyser must find all occurences of new unary operators, and then
    ensure that the user put parentheses around them. What about the old
    unary operators? Are they exempt? This is bad, and it's going to bite
    you.

    >> p29 - array/scalar logic operators; so we can now have built-in
    >> overloading to, for example, AND a std_logic with a SLV4. We can
    >> already do this without a built-in; so what's the point? VHDL is meant
    >> to be strongly typed. Is VHDL-200x also meant to be strongly typed, or
    >> not?

    >Can but unfortunately some synthesis tools don't support it,
    >so hardware designers need something we can use.


    I'd be interested to find out which synthesiser can't infer, for
    example, a single signal being AND'ed with 4 other signals. These
    synthesisers don't need a new built-in, anyway: all they need is a
    standardised package, and they can infer the required functionality
    from the call, using 'builtin' pragmas (which they do already).

    >> p38 - just my personal opinion, of course - HDLs and 'programming'
    >> languages are *very* different. The two common HDLs are 80's dinosaurs
    >> that can't be fixed; one of them wasn't designed, and the other was
    >> designed by a committee. What's the point of trying to shoe-horn
    >> 'real' language features like constrained random generation and all
    >> the rest of it into Verilog or VHDL? They're intended for something
    >> completely different, and they're totally unable to take this extra
    >> infrastructure. There is no point, and it makes no sense whatever,
    >> except for the EDA vendors. If you want the extras, you can already
    >> buy them in appropriate languages that were designed for the job.

    >
    >Looking at SystemVerilog, I see where you are coming from, however,
    >perhaps you should hold your judgement on VHDL until we finish.
    >Something with familiar syntax is much better than something
    >with new syntax and has no formal way to be mixed together.


    There's nothing new about, for example, the 'e' syntax: it's been
    around for maybe 12 years now. It's regular, clean, and almost
    immediately usable by anyone with familiarilty with modern OO
    languages. Talking to VHDL or Verilog, for this example, is trivial
    and pretty much transparent. It's infinitely simpler than using the
    old Verilog PLI was, and the complexity of the Verilog PLI never
    stopped people from using Verilog.

    Besides, this argument ignores a fundamental point. The people who
    write high-level testbenches are generally not the same people who
    code the low-level hardware. They're also more important, in the sense
    that there are more of them, they take up most of your development
    budget, and they're your only way of finding out if you can tapeout or
    not. Given this, why force them to use our hardware languages for a
    task they were never designed for? Only a marketing department could
    possibly have dreamt that up.

    Evan
     
    Evan Lavelle, Nov 6, 2006
    #10
  11. Rick North

    Evan Lavelle Guest

    On Mon, 06 Nov 2006 11:13:19 +0000, Evan Lavelle <>
    wrote:

    >You could try to make the case that you're actually overloading the
    >equality operator in some implicit fashion. But, of course, you'd then
    >have to deal with scope/visibility/implict/explicit/etc. issues.


    Whoops; neuron malfunction. Ignore that.

    Evan
     
    Evan Lavelle, Nov 6, 2006
    #11
  12. Rick North

    Jim Lewis Guest

    Evan,
    >>> p20 - presumably allowing if(cs) instead of if(cs = '1') was to handle
    >>> PSL conditionals? Have you relaxed the typing rules just in this one
    >>> case (and p29)? If so, does it really make sense to break the existing
    >>> typing rules just for this one ad-hoc exception? (And don't all those
    >>> brackets make it look rather C-like? :))

    >>
    >> It is more like adding overloading to conditionals.

    >
    > I would feel better about this if you could point to any other
    > languages that do this; I don't understand the concept of 'overloading
    > a conditional'. How could a conditional decide that an arbitrary
    > (non-boolean) enumeration literal is somehow equal to a different
    > (boolean) enumeration literal? Can I make my own enumerated types when
    > one or more literals is also implicitly equal to true? I'm sorry, but
    > I can't see that this makes any sense at all; a character enumeration
    > literal, such as '1', has no special significance other than to a
    > synthesiser.


    It is not arbitrary, there is a condition operator, "??", that is
    overloaded in the standard packages for bit and std_ulogic.
    Given that simulation vendors optimize standard packages, I would
    expect this to work just like they were built-in to the syntax of
    condition. While you can write your own overloading, bit and std_ulogic
    are the only ones I plan on using.

    I am not worried about the academics as to whether another language
    does this or not, I am looking to get a specific job done in a
    simplified manner without any serious penalties and this does it.
    And it does it in a way that is extensible should we need to add
    to it in the future.

    >>> p28 - unary reduction operators. I've got a bad feeling about this.
    >>> Doesn't it cause confusion in Verilog code? Which is better - "a <=
    >>> xor b xor c", or "a <= xor_reduce(b) xor c"?

    >> Correcting your assignment: a <= (xor b) xor c ;
    >> When a unary reduction operator is used in an expression,
    >> parentheses are required.

    >
    > But the analyser doesn't need parentheses, so this is just *required*
    > syntactic sugar. Any what about "a <= xor b"? Is this a syntax error?
    > Does it have to be "a <= (xor b)"?


    Only needs parentheses when used in an expression with other operators.


    >>> p38 - just my personal opinion, of course - HDLs and 'programming'
    >>> languages are *very* different. The two common HDLs are 80's dinosaurs
    >>> that can't be fixed; one of them wasn't designed, and the other was
    >>> designed by a committee. What's the point of trying to shoe-horn
    >>> 'real' language features like constrained random generation and all
    >>> the rest of it into Verilog or VHDL? They're intended for something
    >>> completely different, and they're totally unable to take this extra
    >>> infrastructure. There is no point, and it makes no sense whatever,
    >>> except for the EDA vendors. If you want the extras, you can already
    >>> buy them in appropriate languages that were designed for the job.

    >>
    >> Looking at SystemVerilog, I see where you are coming from, however,
    >> perhaps you should hold your judgement on VHDL until we finish.
    >> Something with familiar syntax is much better than something
    >> with new syntax and has no formal way to be mixed together.

    >
    > There's nothing new about, for example, the 'e' syntax: it's been
    > around for maybe 12 years now. It's regular, clean, and almost
    > immediately usable by anyone with familiarilty with modern OO
    > languages. Talking to VHDL or Verilog, for this example, is trivial
    > and pretty much transparent. It's infinitely simpler than using the
    > old Verilog PLI was, and the complexity of the Verilog PLI never
    > stopped people from using Verilog.
    >
    > Besides, this argument ignores a fundamental point. The people who
    > write high-level testbenches are generally not the same people who
    > code the low-level hardware. ...
    > Given this, why force them to use our hardware languages for a
    > task they were never designed for?


    Not forcing, just giving them a choice.

    Certainly Verification Engineers look at RTL code. Wouldn't
    it be easier for them if the code were in a language consistent
    with their verification language. Likewise for RTL engineers.

    > Only a marketing department could possibly have dreamt that up.


    Ironic statement. My thought is that the only reason 'e' is a
    separate language is due to business reasons. If they had
    instead made an extension to VHDL or Verilog, how long would they
    have been able to compete with the rest of the market?

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 6, 2006
    #12
  13. Rick North

    Andy Guest

    Jim Lewis wrote:

    > The more I look at this the more I am convinced that
    > an HDL never should have had type boolean. Hind sight.


    Wait, you cannot have it both ways! VHDL was the first HDL that
    actually had most real (for its day) programming language features.
    Booleans are part and parcel of that approach. Among other things they
    allow you to anonymously store results of logical expressions for later
    use. I'd call that a pretty basic need. Call them "architecture neutral
    bits" if you have to. But the reasons most of us preferred vhdl over
    verilog in the first place are becoming more and more blurry, and with
    SystemVerilog available now, we need to capitalize on the advantages of
    strong typing, not weaken it to the same watered-down milk toast of
    [system]verilog. If you think teaching vhdl is hard to do now, just
    wait until some of these changes get implemented. "Well, Mr Student,
    vhdl is sort of strongly typed... you can do this here, but you cannot
    do that there..."

    Frankly, I wish there was a standard definition for an unconstrained
    boolean array, such that I could use it in port definitions without
    having to package it. I'm for using more boolean, not less!

    Andy

    >
    > > p24 - signal expressions in port maps -
    > > p25 - reading output ports -

    > Long time coming.
    >
    > > p26 - "allow conditional assignments for signals and variables in
    > > sequential code". A useful addition to clean up some verbosity? Or
    > > just two ways to do exactly the same thing because the first way was
    > > too verbose? Basic tenet of language design: don't give users multiple
    > > ways to do the same thing. In particular, don't wait 20+ years then do
    > > a partial syntactic up-sugaring exercise. If you wanted to fix the
    > > syntax, you should have done it properly, or not at all. Sorry.... :)
    > >
    > > p27 - allowing selected assignments in sequential code - ditto; even
    > > more so.

    > From a uniformity perspective, these statements can now be used in
    > both concurrent and sequential code. Uniformity is good.
    >
    > >
    > > p28 - unary reduction operators. I've got a bad feeling about this.
    > > Doesn't it cause confusion in Verilog code? Which is better - "a <=
    > > xor b xor c", or "a <= xor_reduce(b) xor c"?

    >
    > Correcting your assignment: a <= (xor b) xor c ;
    > When a unary reduction operator is used in an expression,
    > parentheses are required.
    >
    > > p29 - array/scalar logic operators; so we can now have built-in
    > > overloading to, for example, AND a std_logic with a SLV4. We can
    > > already do this without a built-in; so what's the point? VHDL is meant
    > > to be strongly typed. Is VHDL-200x also meant to be strongly typed, or
    > > not?

    > Can but unfortunately some synthesis tools don't support it,
    > so hardware designers need something we can use.
    >
    > > p36 - very confusing; you need to read p37 in detail to understand it.
    > > Even then, it's still confusing - what's the "Logic, Addition" row?

    > Overloading that is common to both Logic and Addition operators.
    > Operator naming per 1076.
    >
    > > Are any of these rows meant to cover exisiting vendor-specific
    > > std_logic_unsigneds? They don't seem to.

    >
    > No. Operators in std_logic_arith and std_logic_unsigned will
    > not be locally static. Very compelling reason to switch for
    > those who have not.
    >
    > > p38 - just my personal opinion, of course - HDLs and 'programming'
    > > languages are *very* different. The two common HDLs are 80's dinosaurs
    > > that can't be fixed; one of them wasn't designed, and the other was
    > > designed by a committee. What's the point of trying to shoe-horn
    > > 'real' language features like constrained random generation and all
    > > the rest of it into Verilog or VHDL? They're intended for something
    > > completely different, and they're totally unable to take this extra
    > > infrastructure. There is no point, and it makes no sense whatever,
    > > except for the EDA vendors. If you want the extras, you can already
    > > buy them in appropriate languages that were designed for the job.

    >
    > Looking at SystemVerilog, I see where you are coming from, however,
    > perhaps you should hold your judgement on VHDL until we finish.
    > Something with familiar syntax is much better than something
    > with new syntax and has no formal way to be mixed together.
    >
    > > Have any vendors shown any interest in actually implementing
    > > "Accellera VHDL-2006"?

    > The ones I have talked to are actively working on it.
    >
    >
    > >> Everything Accellera standardizes will eventually become an
    > >> IEEE standard - it is just faster to do it in Accellera first.

    > >
    > > If any single statement could encapsulate why the IEEE is totally
    > > irrelevant in language standardisation, this is it. Why doesn't
    > > Accellera have the balls to issue its own standards, instead of
    > > pretending that they're independent IEEE standards? They're not; I
    > > think most people appreciate this now.

    >
    > From a standards perspective, we made good progress under IEEE,
    > however, IEEE did not have infrastructure to fund the effort.
    > Now with CAG, perhaps there is a way to do it all under IEEE.
    > Time will tell. I don't expect to explore this option though
    > unless we have a compelling reason to do so.
    >
    > Cheers,
    > Jim
    > --
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    > Jim Lewis
    > Director of Training mailto:
    > SynthWorks Design Inc. http://www.SynthWorks.com
    > 1-503-590-4787
    >
    > Expert VHDL Training for Hardware Design and Verification
    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Andy, Nov 6, 2006
    #13
  14. Rick North

    Jim Lewis Guest

    Andy,
    >> The more I look at this the more I am convinced that
    >> an HDL never should have had type boolean. Hind sight.

    >
    > Wait, you cannot have it both ways! VHDL was the first HDL that
    > actually had most real (for its day) programming language features.
    > Booleans are part and parcel of that approach.


    I would prefer to use '0' and '1' as they are a little
    closer to the real hardware and would seem to be a better
    representation for true and false for an HDL. However,
    little point in arguing, no one will let me remove boolean.

    > Among other things they
    > allow you to anonymously store results of logical expressions for later
    > use. I'd call that a pretty basic need. Call them "architecture neutral
    > bits" if you have to.


    Logical operators return a std_ulogic if their inputs are std_ulogic.
    Comparisions return boolean. How do I mix these? I have to compose
    something with a conditional. Yuck. This is not about strong typing.
    This is about basic composability. Which do you prefer:

    Y_sl <= '1' when D_sel = '1' and Addr = X"A5A5" else '0' ;
    Y_bool <= D_sel = '1' and Addr = X"A5A5" ;
    Y_new_sl <= D_sel and Addr ?= X"A5A5" ; -- with new operators

    Note that the expression for Y_new_sl is also more accurate in that if
    D_sel = 1 and addr = XX, then the result is X. Also note with the
    conditional extensions the following is also legal:
    process (all)
    begin
    ...
    if D_sel and Addr ?= X"A5A5" then

    end if ;
    end process ;

    What in the strong typing do you believe was broken?
    What has happened is overloading is now present in the context
    of a conditional. Also some new comparison operators were added
    (?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
    Note that the top level of a conditional must
    evaluate to either boolean, bit, or std_ulogic then a conversion
    is applied - note that there is no generalized implicit conversion
    that converts boolean to bit or std_ulogic, or vice-versa.

    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 6, 2006
    #14
  15. Rick North

    KJ Guest

    "Jim Lewis" <> wrote in message
    news:...
    >
    > Logical operators return a std_ulogic if their inputs are std_ulogic.
    > Comparisions return boolean. How do I mix these? I have to compose
    > something with a conditional. Yuck. This is not about strong typing.
    > This is about basic composability. Which do you prefer:
    >
    > Y_sl <= '1' when D_sel = '1' and Addr = X"A5A5" else '0' ;
    > Y_bool <= D_sel = '1' and Addr = X"A5A5" ;
    > Y_new_sl <= D_sel and Addr ?= X"A5A5" ; -- with new operators
    >

    Personally I simply use a boolean to std_ulogic conversion function and
    write either...
    Y_sl <= to_std_ulogic(D_sel = '1' and Addr = X"A5A5")
    or (assuming D_sel is already std_ulogic)

    Y_sl <= D_sel and to_std_ulogic(Addr = X"A5A5");

    Either form I think is generally just as expressive of design intent as the
    new forms that are creeping in. Granted there is more typing involved in
    typing 'to_std_ulogic' than there is with '?=' but in exchange you get the
    obvious advantage that 'to_std_ulogic' is not as cryptic as '?=' and more
    clearly expresses design intent (i.e. to do a type conversion).

    'to_std_ulogic' keeps with the strong typing of the existing language and
    the use of type conversion functions that strong typing generally implies
    using at some point. Why nobody thought to include a 'to_std_logic'
    function that converts boolean 'to std_logic' as part of an ieee standard
    package baffled me (years ago) but I took the 30 seconds to write it and
    include it in a package of 'things I commonly use' and got on with life.

    > Note that the expression for Y_new_sl is also more accurate in that if
    > D_sel = 1 and addr = XX, then the result is X.


    That's a benefit.

    KJ
     
    KJ, Nov 7, 2006
    #15
  16. Rick North

    Evan Lavelle Guest

    On Mon, 06 Nov 2006 13:59:02 -0800, Jim Lewis <>
    wrote:

    >Logical operators return a std_ulogic if their inputs are std_ulogic.
    >Comparisions return boolean. How do I mix these?


    Logical operators on std_ulogics are user-defined, and return whatever
    you want them to; even a boolean.

    >
    > ...
    > if D_sel and Addr ?= X"A5A5" then
    >
    > end if ;
    > end process ;
    >
    >What in the strong typing do you believe was broken?


    Is D_sel a std_ulogic and the result of the comparison a boolean?
    std_ulogic is a user-defined enumeration type composed of arbitrary
    character literals. Boolean is a predefined enumeration type. Are you
    also saying that that the predefined 'and' operator will now carry out
    an operation between a user-defined enumeration and a boolean, and
    will return a boolean? If so, how can you *possibly* state that strong
    typing has not been broken? It's broken; period.

    >What has happened is overloading is now present in the context
    >of a conditional.


    This statement makes no sense. To be more precise, you are suggesting
    that the analyser must determine the context of every expression, and
    use that context to determine what type the operands can be, and what
    the return type can be. I've pointed this out before, and you provided
    no justification.

    As I've also pointed out before there is, I think, a rigorous fix,
    which involves introducing a new type into the language. Again, I'd be
    interested to hear why you think this doesn't work.

    >of a conditional. Also some new comparison operators were added
    >(?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
    >Note that the top level of a conditional must
    >evaluate to either boolean, bit, or std_ulogic then a conversion


    Have you promoted std_ulogic from a user-defined type to a built-in
    type? Is std_ulogic now described in the LRM? If not, you can't do any
    of this.

    Evan
     
    Evan Lavelle, Nov 7, 2006
    #16
  17. Rick North

    Jim Lewis Guest

    Evan,
    >> What in the strong typing do you believe was broken?

    >
    > Is D_sel a std_ulogic and the result of the comparison a boolean?

    Nope. The comparison uses the new operators, ?=, ?/=, ?>, ?>=, ?<, ?<=,
    that return bit and std_ulogic (via overloading in appropriate packages).

    > std_ulogic is a user-defined enumeration type composed of arbitrary
    > character literals. Boolean is a predefined enumeration type. Are you
    > also saying that that the predefined 'and' operator will now carry out
    > an operation between a user-defined enumeration and a boolean, and
    > will return a boolean?

    Nope.

    > If so, how can you *possibly* state that strong
    > typing has not been broken? It's broken; period.


    Well designed overloading is an essential part of strongly typed
    language. Both numeric_std and std_logic_arith allow the following:

    Y_Signed <= A_Signed + B_int ;

    Does this break strong typing?


    >> What has happened is overloading is now present in the context
    >> of a conditional.

    >
    > This statement makes no sense. To be more precise, you are suggesting
    > that the analyser must determine the context of every expression, and
    > use that context to determine what type the operands can be, and what
    > the return type can be. I've pointed this out before, and you provided
    > no justification.


    The overloading only gets applied at the top level of a condition,
    so the analyzer is not looking at every expression.

    The overloading is not arbitrary, there is a condition operator, "??",
    that is overloaded in the standard packages for bit and std_ulogic.
    Given that simulation vendors optimize standard packages, I would
    expect this to work just like they were built-in to the syntax of
    condition. While one could further overload "??", bit and
    std_ulogic are the only ones I plan on using.

    BTW, this is not a language proposal, these features are already part
    of Accellera VHDL-2006 standard 3.0, so if you join the Accellera VHDL
    TSC (which you can do as a non-accellera member), you can download the
    standard and read the details. This feature has been designed and
    reviewed by people who understand the working of the analyzer much
    better than myself.

    > As I've also pointed out before there is, I think, a rigorous fix,
    > which involves introducing a new type into the language. Again, I'd be
    > interested to hear why you think this doesn't work.


    Why introduce a new type when the current solution works just fine
    with types that we have already made friends with? Besides the
    current solution is in the current Accellera standard and is being
    implemented by vendors.


    >> of a conditional. Also some new comparison operators were added
    >> (?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
    >> Note that the top level of a conditional must
    >> evaluate to either boolean, bit, or std_ulogic then a conversion

    >
    > Have you promoted std_ulogic from a user-defined type to a built-in
    > type? Is std_ulogic now described in the LRM?


    Yes. ?=, ?/=, ?>, ?>=, ?<, ?<= are pre-defined in
    the LRM for types bit and std_ulogic.

    ?=, ?/= are defined for any one dimensional array type whose
    element type is BIT, BOOLEAN or a subtype of STD_ULOGIC.

    Note for array types, the operators, ?>, ?>=, ?<, and ?<=, must
    be overloaded - hence - if you only use std_logic_1164, you do
    not have any implicit ordering comparison operators to worry
    about. With vhdl-87 comparisons, the following is true:
    Y_bool <= std_logic_vector'("10") > std_logic_vector'("0100") ;

    With the ordering comparison operators the following is an error,
    unless you have referenced a package that explicitly defines "?>"
    (such as numeric_std_unsigned):
    Y_bool <= std_logic_vector'("10") ?> std_logic_vector'("0100") ;


    > If not, you can't do any of this.

    Actually all the LRM only needs to define the operators for
    some type, such as bit, and then it can overload it separately for
    std_ulogic.


    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 7, 2006
    #17
  18. Rick North

    Evan Lavelle Guest

    On Tue, 07 Nov 2006 10:26:13 -0800, Jim Lewis <>
    wrote:

    >> std_ulogic is a user-defined enumeration type composed of arbitrary
    >> character literals. Boolean is a predefined enumeration type. Are you
    >> also saying that that the predefined 'and' operator will now carry out
    >> an operation between a user-defined enumeration and a boolean, and
    >> will return a boolean?

    >Nope.
    >
    >> If so, how can you *possibly* state that strong
    >> typing has not been broken? It's broken; period.


    The details of this argument depend very much on the extent to which
    std_ulogic is now part of the base language, and on the extent to
    which all this is implemented by overloading. I don't know these
    details, so I'll have to pass. It certainly appears to me, from what
    I've read here, that either nothing has been achieved beyond what we
    can already achieve by overloading, or that strong typing has been
    broken. If I can indeed write "if(Y_stdulogic)" then it's self-evident
    that strong typing has been broken.

    >Well designed overloading is an essential part of strongly typed
    >language. Both numeric_std and std_logic_arith allow the following:
    >
    > Y_Signed <= A_Signed + B_int ;
    >
    >Does this break strong typing?


    No, because 'signed' is a user-defined type, and the packages are also
    user-defined. If you'd instead asked 'Does 'Y_bool <= A_int + b_bool'
    break strong typing, without the use of user-defined overloading, then
    my answer would have been 'yes'. The user-extensibility of VHDL gives
    us a 'get out of jail free' card. The base language does not give you
    this; that is the nature of strong typing. If you disagree, then I'd
    like to hear your definition of 'strong typing'.

    >>> What has happened is overloading is now present in the context
    >>> of a conditional.

    >>
    >> This statement makes no sense. To be more precise, you are suggesting
    >> that the analyser must determine the context of every expression, and
    >> use that context to determine what type the operands can be, and what
    >> the return type can be. I've pointed this out before, and you provided
    >> no justification.

    >
    >The overloading only gets applied at the top level of a condition,
    >so the analyzer is not looking at every expression.


    Speaking with my compiler-writer hat on, I would say that an analyser
    is not likely to work the way that your statement implies. The
    proposed extension means that the value of an object depends on the
    context of that object. The value of an object is required when
    analysing most of an AST. It is unlikely that a compiler writer would
    start from the top of an AST, find every conditional expression, and
    descend down to modify the value of the object required by the
    conditional. It's much more practical, IMO at least, to carry out
    normal analysis, to look back up the AST to determine the context of
    the current object, and to modify its value accordingly. In other
    words, the compiler will have to look at every expression to handle
    this kludge.

    >BTW, this is not a language proposal, these features are already part
    >of Accellera VHDL-2006 standard 3.0, so if you join the Accellera VHDL
    >TSC (which you can do as a non-accellera member), you can download the
    >standard and read the details.


    I was under the impression that the IEEE still owns the copyright on
    the LRM; there is, I think, no "Accellera VHDL-2006". However, given
    the current state of IEEE-SA, I have no doubt that you'll get your
    way, whether or not it makes sense.

    Evan
     
    Evan Lavelle, Nov 8, 2006
    #18
  19. Rick North

    Jim Lewis Guest

    Evan,
    > I was under the impression that the IEEE still
    > owns the copyright on the LRM;


    Yes, but ...
    Accellera VHDL TSC and IEEE VASG have a message of understanding
    under which the Accellera VHDL TSC has been granted the right
    to make revisions of the standard. Feel free to check out the
    VASG webpage:
    http://www.eda-stds.org/vasg/

    You will note that this was announced on the VHDL-200X reflector:
    http://www.eda.org/vhdl-200x/hm/0885.html


    > there is, I think, no "Accellera VHDL-2006".


    You will find the Accellera press release at:
    http://www.accellera.org/pressroom/2006/AccelleraVHDL100906.pdf


    Cheers,
    Jim
    --
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Jim Lewis
    Director of Training mailto:
    SynthWorks Design Inc. http://www.SynthWorks.com
    1-503-590-4787

    Expert VHDL Training for Hardware Design and Verification
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     
    Jim Lewis, Nov 8, 2006
    #19
  20. Rick North

    KJ Guest

    "Jim Lewis" <> wrote in message
    news:...
    <snip> Also note with the
    > conditional extensions the following is also legal:
    > process (all)
    > begin
    > ...
    > if D_sel and Addr ?= X"A5A5" then
    >
    > end if ;
    > end process ;
    >
    > What in the strong typing do you believe was broken?
    > What has happened is overloading is now present in the context
    > of a conditional. Also some new comparison operators were added
    > (?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
    > Note that the top level of a conditional must
    > evaluate to either boolean, bit, or std_ulogic then a conversion
    > is applied - note that there is no generalized implicit conversion
    > that converts boolean to bit or std_ulogic, or vice-versa.


    Jim,

    I'm confused. Does the statement

    if D_sel and Addr ?= X"A5A5" then

    evaluate to a 'yes/no' decision or not? Does

    if D_sel then

    evaluate to a 'yes/no' decision (D_sel being a std_ulogic)? If yes for
    either of these then how? If this is valid then what path is taken if
    'D_sel' is unknown? The 'yes' path or the 'no' path? Why?

    Taking some liberties in mixing old speak and new speak VHDL, it 'seems'
    like these if statements are in someway roughly equivalent to

    if To_X01(D_sel and Addr ?= X"A5A5") = '1' then
    if To_X01(D_sel and To_Std_Logic(Addr = X"A5A5")) = '1' then
    or
    if To_X01(D_sel) = '1' then

    where 'To_Std_Logic' is my previously mentioned boolean to std_ulogic
    conversion function which maintains strong typing

    and where if the std_ulogic happens to evalutate to '1' (or 'H') that the
    'yes' path is taken otherwise the 'no' path is taken. If this is the case,
    then it seems to be a poor reason for weakening the strong typing. The
    alternative would be that conditionals would now need to have three paths so
    an if statement would be of the form

    if D_sel
    -- Do stuff as if To_X01(D_Sel) = '1'
    mostlyelse
    -- Do stuff as if To_X01(D_Sel) = '0'
    unknownelse
    -- Do stuff as if To_X01(D_Sel) = 'X'
    end if;

    And I'm pretty sure that you're not proposing this kind of change to the
    'if' statement.

    KJ
     
    KJ, Nov 11, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Ivan C.
    Replies:
    4
    Views:
    963
    David Bishop
    Nov 21, 2004
  2. Replies:
    6
    Views:
    1,976
    Divyang M
    Dec 14, 2004
  3. Divyang M
    Replies:
    3
    Views:
    621
    David Bishop
    Feb 4, 2005
  4. Jim Lewis

    Request for Support: VHDL-200X

    Jim Lewis, Feb 28, 2005, in forum: VHDL
    Replies:
    0
    Views:
    518
    Jim Lewis
    Feb 28, 2005
  5. Jim Lewis
    Replies:
    0
    Views:
    485
    Jim Lewis
    Feb 28, 2005
Loading...

Share This Page