News on VHDL-200X

[Rick North]

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

 

[Kim Enkovaara]

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

 

[Ajeetha]

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

 

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

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

 

[KJ]

"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:12leonlmp8u3d8d@corp.supernews.com...

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

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

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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

 

[Jim Lewis]

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:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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