IF Statement

Discussion in 'VHDL' started by graeme.cunningham@googlemail.com, Nov 1, 2006.

  1. Guest

    Is the following legal VHDL code

    if A then

    Or does value of A have to explicitly defined, such as ...

    if A = '1' then

    I know that in verilog the use of
    if (a)

    and

    if (a=1)

    are permited.

    Thanks in advance.
    g
     
    , Nov 1, 2006
    #1
    1. Advertising

  2. Ben Jones Guest

    Hi Graeme,

    <> wrote in message
    news:...
    > Is the following legal VHDL code
    >
    > if A then
    >
    > Or does value of A have to explicitly defined, such as ...
    >
    > if A = '1' then


    Where A is of boolean type, the "if A then ..." syntax is OK.

    But, for types bit or std_logic, you need that comparison. There is no
    implicit conversion to boolean.

    Cheers,

    -Ben-
     
    Ben Jones, Nov 1, 2006
    #2
    1. Advertising

  3. Frank Buss Guest

    Frank Buss, Nov 1, 2006
    #3
  4. Frank Buss Guest

    Ben Jones wrote:

    > But, for types bit or std_logic, you need that comparison. There is no
    > implicit conversion to boolean.


    For operators you can define operator overloading, like
    function "not" (l: std_logic) return boolean;
    and then you can write "if not a then". But is it possible to define a
    function for implicit type conversion in VHDL, like in C++? (see e.g.
    http://www.devx.com/tips/Tip/12459 ) Then you could write "if a then", even
    if "a" is a std_logic variable.

    --
    Frank Buss,
    http://www.frank-buss.de, http://www.it4-systems.de
     
    Frank Buss, Nov 1, 2006
    #4
  5. Andy Guest

    I'm pretty sure that's coming in the next release of the standard
    (implicit conversion of std_ulogic to boolean). In some ways, I'm in
    favor of it, but in others I'm not. Today, all synthesis tools
    interpret a boolean true as a logic '1' anyway, but that need not be
    true, and could allow optimizations (like those done on state machines)
    to come up with optimal mappings between boolean and logic values. With
    this change, though, we are forever defining boolean true as logic '1'
    in the language. I also do not like the way active low signals are
    handled (if not a_n then) in implicit conversions.

    I've always written and used is1() and is0() functions, since they can
    properly handle metavalues (and assert a warning if ambiguous: u,-,x,
    etc.). It is unclear to me how that will be handled in the new
    standard.

    I use a lot of booleans for internal "flag" signals/variables so that
    no function or conversion is necessary.

    Andy


    Frank Buss wrote:
    > wrote:
    >
    > > Is the following legal VHDL code
    > >
    > > if A then

    >
    > yes, if a is of type boolean.
    >
    > --
    > Frank Buss,
    > http://www.frank-buss.de, http://www.it4-systems.de
     
    Andy, Nov 1, 2006
    #5
  6. Andy wrote:

    > I've always written and used is1() and is0() functions, since they can
    > properly handle metavalues (and assert a warning if ambiguous: u,-,x,
    > etc.). It is unclear to me how that will be handled in the new
    > standard.


    Yes.
    I named mine now_high, now_low to boolean
    and active_high, active_low to std_ulogic

    Functions like these ought to added
    to some standard library.

    > I use a lot of booleans for internal "flag" signals/variables so that
    > no function or conversion is necessary.


    Good point.
    A non-trivial design has more internal objects
    than external, and these can be whatever type
    I prefer.

    -- Mike Treseler
     
    Mike Treseler, Nov 1, 2006
    #6
  7. Jim Lewis Guest

    Andy,
    > I'm pretty sure that's coming in the next release of the standard
    > (implicit conversion of std_ulogic to boolean). In some ways, I'm in
    > favor of it, but in others I'm not.

    The conversion only is applied implicitly at the outermost
    level of a condition.


    > Today, all synthesis tools
    > interpret a boolean true as a logic '1' anyway, but that need not be
    > true, and could allow optimizations (like those done on state machines)
    > to come up with optimal mappings between boolean and logic values. With
    > this change, though, we are forever defining boolean true as logic '1'
    > in the language.

    ???
    Assigning a signal to '1' or TRUE does not guarantee that it
    will be synthesized to a high level. Perhaps you have this
    notion since historically some synthesis tools preserved signals
    at interfaces, however, now I see tools not only flip values of
    signals at interfaces, they also move logic and multiple signals
    through the block interface boundary.

    > I also do not like the way active low signals are
    > handled (if not a_n then) in implicit conversions.

    Then write it as:

    if a_n ?= '0' then

    Note that this will work in multiple operator expressions
    since "?=" returns a std_ulogic value. Note that you can also use
    "=" for single operator expressions like this, but you cannot
    mix it with other std_ulogic values. Whereas since "?=" returns
    std_ulogic, it can be mixed with other std_ulogic operations.
    Also ?= properly handles '-'.

    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 1, 2006
    #7
  8. Andy Guest

    Jim,

    With regard to combinatorial signals in logic chains, yes, signals get
    "optimized" all the time. If I have a high-true output that gets
    inverted in another module, the system may "combine" the logic on both
    sides of the inteface, and get rid of the separate inversion, but I
    have never seen it done if the output was a registered signal, unless
    register retiming was enabled.

    What I'm talking about is, similarly to state mapping optimization, if
    the synthesis tool figures out that it is more efficient to invert the
    sense of a registered value, then they invert the register. Again,
    without enabling register retiming, I've never seen that happen, though
    my experience is almost entirely in LUT based FPGAs, where such a
    change of sense rarely makes a difference. Such optimizations make
    formal analysis very difficult too.

    In the end, I suppose you're right, with the exception of primary IO
    (where, by golly, if I say something needs to be a '1', it better be a
    logic high!), in that there should not be any difference in the notion
    of optimizing the sense of booleans as opposed to bits or sl values.

    Interesting point about the new ?= operator, though I hate the syntax.
    Stinks of C to me! But that's just me... And right around the corner
    will be a <= condition ? b, c; !!! If people want to write C, let them
    compile it with a C compiler, don't mess up VHDL.

    Andy


    Jim Lewis wrote:
    > Andy,
    > > I'm pretty sure that's coming in the next release of the standard
    > > (implicit conversion of std_ulogic to boolean). In some ways, I'm in
    > > favor of it, but in others I'm not.

    > The conversion only is applied implicitly at the outermost
    > level of a condition.
    >
    >
    > > Today, all synthesis tools
    > > interpret a boolean true as a logic '1' anyway, but that need not be
    > > true, and could allow optimizations (like those done on state machines)
    > > to come up with optimal mappings between boolean and logic values. With
    > > this change, though, we are forever defining boolean true as logic '1'
    > > in the language.

    > ???
    > Assigning a signal to '1' or TRUE does not guarantee that it
    > will be synthesized to a high level. Perhaps you have this
    > notion since historically some synthesis tools preserved signals
    > at interfaces, however, now I see tools not only flip values of
    > signals at interfaces, they also move logic and multiple signals
    > through the block interface boundary.
    >
    > > I also do not like the way active low signals are
    > > handled (if not a_n then) in implicit conversions.

    > Then write it as:
    >
    > if a_n ?= '0' then
    >
    > Note that this will work in multiple operator expressions
    > since "?=" returns a std_ulogic value. Note that you can also use
    > "=" for single operator expressions like this, but you cannot
    > mix it with other std_ulogic values. Whereas since "?=" returns
    > std_ulogic, it can be mixed with other std_ulogic operations.
    > Also ?= properly handles '-'.
    >
    > 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 2, 2006
    #8
  9. Jim Lewis Guest

    Andy,
    > Interesting point about the new ?= operator, though I hate the syntax.
    > Stinks of C to me! But that's just me...

    With time I think you will like it. The more I tinker with it,
    the more I like it. Hind sight, I think the language would be
    more robust without boolean. That way there would only be one
    set of conditional operators which returned a bit/std_ulogic value.

    > And right around the corner
    > will be a <= condition ? b, c; !!! If people want to write C, let them
    > compile it with a C compiler, don't mess up VHDL.

    Hey - not on my watch.

    We considered an expression of the form: A when condition else B
    However due to waveforms in signal assignments it would not work.

    We considered an expression of the form: A if condition else B
    However the C programmers did not like it.

    We considered an expression of the form: A if condition, B
    However that would be weird in a subprogram call and
    hence it was ditched.

    As a result, we ended up expanding conditional signal assignment
    to be allowed both concurrently and sequentially as well as allowing
    it to be used for variables (likewise for selected assignment):
    Y <= 8D"255" when A > 255 else A ;


    We may reconsider the following: A if condition else B
    I like this best of all since it differentiates if from
    case (particularly selected signal assignment), but this
    will only happen if someone else brings it up.

    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 2, 2006
    #9
    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. Replies:
    3
    Views:
    823
  2. Jay McGavren
    Replies:
    11
    Views:
    1,169
    Alan Krueger
    Jan 16, 2006
  3. tedsuzman
    Replies:
    2
    Views:
    7,147
    Michel Claveau, résurectionné d'outre-bombe inform
    Jul 21, 2004
  4. Ted
    Replies:
    1
    Views:
    485
    Duncan Booth
    Jul 22, 2004
  5. Replies:
    21
    Views:
    1,078
    Giannis Papadopoulos
    Aug 2, 2005
Loading...

Share This Page