News on VHDL-200X

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

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 private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Jim Lewis

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

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

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

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/vhd...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.
>
>

burn.sir@gmail.com

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

"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

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 private.php?do=newpm&u=
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

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

Jim Lewis

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