IF Statement

[graeme.cunningham]

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

 

[Ben Jones]

Hi Graeme,

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-

 

[Frank Buss]

Is the following legal VHDL code

if A then

yes, if a is of type boolean.

 

[Frank Buss]

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.

 

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

 

[Mike Treseler]

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

 

[Jim Lewis]

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:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Andy]

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]

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:[email protected]
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~