News on VHDL-200X

[Jim Lewis]

KJ,

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

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

There is an error in your statement here.
In your example, the to_std_logic is required because
conditionals ("=" ...) return type boolean which
in all definitions of the language is incompatible with
std_ulogic, so you are obligated to convert it and in some
instances (assignments) loose information.

The new overloading requires a condition, in its entirety,
to evaluate to either boolean, std_ulogic, or bit, otherwise
it is an error. The strong typing is still there.

The addition of the "?=" family of operators does not
disturb strong typing either.

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

> If this is the case,
then it seems to be a poor reason for weakening the strong typing.

Since the condition must evaluate in its entirety
to boolean, std_ulogic, or bit, the strong typing
is still there - and it is not any weaker.

For years people have used similar arguments to
keep changes like reading output ports (because
ADA does this - although it was removed in ADA-95),
expressions in port maps, use of the key word
all in place of signals in the sensitivity list
(because having all the signals there is good
documentation), only being able to do conditional
assignments concurrently (because this language
feature is only for dataflow type code and because
you can do it with an if statement in sequential code),
....

Someone always has an argument against one thing or another.
As a result, compromise is the only way to move forward.
The quote I have heard about working on standards is you
do not always get what you want, but you usually end up
with something you can live with.

The problem I see is that while some are attached to
converting std_ulogic/std_logic to boolean using "=",
many others desire not to have to do this.

If you had it all to do over again, doesn't seem odd
to have to fight with the language to convert to boolean
and back again, when many things are more naturally a
bit value (0, 1, X)? So why not make some language
design corrections that account of this.

Overloading a condition to understand std_ulogic and bit
seems to be a reasonable solution. Providing conditionals
that return bit/std_ulogic seems to another logical
extension.

alternative would be that conditions 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;

Nope.

Keep in mind the intent of a strongly typed language is
help you write correct code. I think the more uniform
and consistent you make a language, the easier it is to
compose code and get it right. Since logic designers
often work in one of the bit types (std_ulogic, ...),
I think having a condition accept a bit type
makes the language more uniform and as a result makes
one less likely to make errors.

I don't think the current situation of having to
add "=" and to_std_logic to a condition is going
to make your code any safer from errors. Actually
I think that since it differs from the syntax one
commonly uses for assignments to bit values, that
it actually makes one more likely to make errors.
However, since the change is fully backward compatible,
you are free to keep composing your conditions so they
result in boolean.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[KJ]

KJ,

There is an error in your statement here.
In your example, the to_std_logic is required because
conditionals ("=" ...) return type boolean which
in all definitions of the language is incompatible with
std_ulogic, so you are obligated to convert it

Yes, being upfront about my type conversions is a 'good' thing if you
believe that strong typing is also a 'good' thing.

and in some
instances (assignments) loose information.

I agree, the instances where information is lost are where the std_ulogic
takes on one of the 'meta-logic' values ('Z', 'U', etc.). In that sense
'?=' has a leg up on 'to_std_logic' since, according to your earlier post,
'?=' will return an unknown if one side or the other is unknown (which is a
'good' thing).

The new overloading requires a condition, in its entirety,
to evaluate to either boolean, std_ulogic, or bit, otherwise
it is an error. The strong typing is still there.

But the behaviour of the if statement itself is a bit less clear.
std_ulogic has meta-values and now just to save 5 keystrokes per 'if'
condition ("= '1' ") this behaviour is buried inside the LRM instead of in
plain sight in the code. Back to the days when I first learned C in the
early 80s I found that writing things like

if x

a bit jarring....if x what? Then of course if gets explained that well,
it's if x is not equal to 0 of course. Now years later, we're putting the
same type of syntax into VHDL except the behind the scenes thing that you
have to remember is now the implicit "= '1'"...along with an implicit type
conversion of to_x01() to get the 9 std_ulogic values down to 3 values. So
now when you look at a line of code that says

if x

you can try to remember is it really....
if (x <> '0') -- You have your 'C' hat on
or
if (x = '1') -- You have your 'VHDL-2K+6 hat on'

To which I'll personally just stick with the clearer thing which is simply
to state what I mean and not use the less clear new syntax. If others think
that the new syntax is a good thing and want this in the standard I won't
begrudge them that, they're not breaking my code and if the tool vendors
have no heartburn over it and will still accept my code then knock
yourselves out. Me, I'm a fast enough typist to append on the "= '1'" to my
'if' statements.

To each his/her own, call me neutral on the point. I think it's less clear,
I was just trying to confirm whether my interpretation was correct, thanks.

The addition of the "?=" family of operators does not
disturb strong typing either.

Agreed, the '?=' appears to be a new thing that does adhere to strong
typing...the issue (for those who think it is an issue) seems to be with the
'if' statement.

Someone always has an argument against one thing or another.
As a result, compromise is the only way to move forward.
The quote I have heard about working on standards is you
do not always get what you want, but you usually end up
with something you can live with.

Wasn't arguing one side or the other really was asking for clarification. I
think the new syntax on the 'if' statement makes for less readable code. If
enough people want that and they don't break the more readable code then
like I said, knock yourselves out.

The problem I see is that while some are attached to
converting std_ulogic/std_logic to boolean using "=",
many others desire not to have to do this.

Lots of people like less readable code simply because they don't like to
type.

If you had it all to do over again, doesn't seem odd
to have to fight with the language to convert to boolean
and back again, when many things are more naturally a
bit value (0, 1, X)? So why not make some language
design corrections that account of this.

Overloading a condition to understand std_ulogic and bit
seems to be a reasonable solution. Providing conditionals
that return bit/std_ulogic seems to another logical
extension.

I agree. I'm not forced to use the new 'if' syntax. I just have to live
with it if or when I run across someone else who uses it and I have to look
at their code.....which is far less likely than the ones too tired to type
"= '1'" before the "then" on each and every "if" statement.....you'll get
the kudos from those people.

Keep in mind the intent of a strongly typed language is
help you write correct code. I think the more uniform
and consistent you make a language, the easier it is to
compose code and get it right.

Consistent? You mean like how since the original incarnation of VHDL, I
could only use 'if' and 'case' inside a process but not as a concurrent
statement? Well, 20 years later that got fixed....it did, didn't it? I
thought I read that somewhere

Since logic designers
often work in one of the bit types (std_ulogic, ...),
I think having a condition accept a bit type
makes the language more uniform and as a result makes
one less likely to make errors.

And everyone can have their opinions. As long as their are no subtle
differences when you write/inspect the code and incorrectly have in mind the
implicit "not equal to 0" from your C language software side and the
implicit "equals 1" VHDL side....and are not left with the nagging feeling
that the designer just got lazy when he/she wrote

if x then

I don't think the current situation of having to
add "=" and to_std_logic to a condition is going
to make your code any safer from errors.

Just easier to read and understand and support....my opinion only.

However, since the change is fully backward compatible,
you are free to keep composing your conditions so they
result in boolean.

And that's a definite 'good' thing. Keep up the good work....and maybe even
encourage people to not be so lazy to type

if x='1'

even though the language does allow you to write

if x

Thanks for clarifying.

KJ

 

[Jim Lewis]

KJ

Consistent? You mean like how since the original incarnation of VHDL, I
could only use 'if' and 'case' inside a process but not as a concurrent
statement? Well, 20 years later that got fixed....it did, didn't it? I
thought I read that somewhere

Conditional signal assignment and selected signal assignment
will be able to be used in processes.
If and case are compound statements and will always be
limited to sequential code.
If generate is now permitted to have an else and a case
generate has been added.

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Hans]

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

I emailed Modeltech and they informed me that they are working on it but
couldn't yet give me a release date which is understandable I guess.

Has anybody called/emailed Aldec/Cadence/Synopsys/Symphony/Green Mountain
etc?

Hans
www.ht-lab.com