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

 

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

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

 

[Mike Treseler]

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

 

[Kim Enkovaara]

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

 

[burn.sir]

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



once again, nice job Accellera!
burns

 

[Evan Lavelle]

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

 

[Ben Jones]

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-

 

[Jim Lewis]

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.

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

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

 

[Evan Lavelle]

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.

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.

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

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]

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.

Whoops; neuron malfunction. Ignore that.

Evan

 

[Jim Lewis]

Evan,

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

It is not arbitrary, there is a condition operator, "??", that is
overloaded in the standard packages for bit and std_ulogic.
Given that simulation vendors optimize standard packages, I would
expect this to work just like they were built-in to the syntax of
condition. While you can write your own overloading, bit and std_ulogic
are the only ones I plan on using.

I am not worried about the academics as to whether another language
does this or not, I am looking to get a specific job done in a
simplified manner without any serious penalties and this does it.
And it does it in a way that is extensible should we need to add
to it in the future.

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)"?

Only needs parentheses when used in an expression with other operators.

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. ...
> Given this, why force them to use our hardware languages for a
task they were never designed for?

Not forcing, just giving them a choice.

Certainly Verification Engineers look at RTL code. Wouldn't
it be easier for them if the code were in a language consistent
with their verification language. Likewise for RTL engineers.

> Only a marketing department could possibly have dreamt that up.

Ironic statement. My thought is that the only reason 'e' is a
separate language is due to business reasons. If they had
instead made an extension to VHDL or Verilog, how long would they
have been able to compete with the rest of the market?

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

 

[Andy]

The more I look at this the more I am convinced that
an HDL never should have had type boolean. Hind sight.

Wait, you cannot have it both ways! VHDL was the first HDL that
actually had most real (for its day) programming language features.
Booleans are part and parcel of that approach. Among other things they
allow you to anonymously store results of logical expressions for later
use. I'd call that a pretty basic need. Call them "architecture neutral
bits" if you have to. But the reasons most of us preferred vhdl over
verilog in the first place are becoming more and more blurry, and with
SystemVerilog available now, we need to capitalize on the advantages of
strong typing, not weaken it to the same watered-down milk toast of
[system]verilog. If you think teaching vhdl is hard to do now, just
wait until some of these changes get implemented. "Well, Mr Student,
vhdl is sort of strongly typed... you can do this here, but you cannot
do that there..."

Frankly, I wish there was a standard definition for an unconstrained
boolean array, such that I could use it in port definitions without
having to package it. I'm for using more boolean, not less!

Andy

 

[Jim Lewis]

Andy,

Wait, you cannot have it both ways! VHDL was the first HDL that
actually had most real (for its day) programming language features.
Booleans are part and parcel of that approach.

I would prefer to use '0' and '1' as they are a little
closer to the real hardware and would seem to be a better
representation for true and false for an HDL. However,
little point in arguing, no one will let me remove boolean.

Among other things they
allow you to anonymously store results of logical expressions for later
use. I'd call that a pretty basic need. Call them "architecture neutral
bits" if you have to.

Logical operators return a std_ulogic if their inputs are std_ulogic.
Comparisions return boolean. How do I mix these? I have to compose
something with a conditional. Yuck. This is not about strong typing.
This is about basic composability. Which do you prefer:

Y_sl <= '1' when D_sel = '1' and Addr = X"A5A5" else '0' ;
Y_bool <= D_sel = '1' and Addr = X"A5A5" ;
Y_new_sl <= D_sel and Addr ?= X"A5A5" ; -- with new operators

Note that the expression for Y_new_sl is also more accurate in that if
D_sel = 1 and addr = XX, then the result is X. Also note with the
conditional extensions the following is also legal:
process (all)
begin
...
if D_sel and Addr ?= X"A5A5" then

end if ;
end process ;

What in the strong typing do you believe was broken?
What has happened is overloading is now present in the context
of a conditional. Also some new comparison operators were added
(?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
Note that the top level of a conditional must
evaluate to either boolean, bit, or std_ulogic then a conversion
is applied - note that there is no generalized implicit conversion
that converts boolean to bit or std_ulogic, or vice-versa.

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]

Logical operators return a std_ulogic if their inputs are std_ulogic.
Comparisions return boolean. How do I mix these? I have to compose
something with a conditional. Yuck. This is not about strong typing.
This is about basic composability. Which do you prefer:

Y_sl <= '1' when D_sel = '1' and Addr = X"A5A5" else '0' ;
Y_bool <= D_sel = '1' and Addr = X"A5A5" ;
Y_new_sl <= D_sel and Addr ?= X"A5A5" ; -- with new operators

Personally I simply use a boolean to std_ulogic conversion function and
write either...
Y_sl <= to_std_ulogic(D_sel = '1' and Addr = X"A5A5")
or (assuming D_sel is already std_ulogic)

Y_sl <= D_sel and to_std_ulogic(Addr = X"A5A5");

Either form I think is generally just as expressive of design intent as the
new forms that are creeping in. Granted there is more typing involved in
typing 'to_std_ulogic' than there is with '?=' but in exchange you get the
obvious advantage that 'to_std_ulogic' is not as cryptic as '?=' and more
clearly expresses design intent (i.e. to do a type conversion).

'to_std_ulogic' keeps with the strong typing of the existing language and
the use of type conversion functions that strong typing generally implies
using at some point. Why nobody thought to include a 'to_std_logic'
function that converts boolean 'to std_logic' as part of an ieee standard
package baffled me (years ago) but I took the 30 seconds to write it and
include it in a package of 'things I commonly use' and got on with life.

Note that the expression for Y_new_sl is also more accurate in that if
D_sel = 1 and addr = XX, then the result is X.

That's a benefit.

KJ

 

[Evan Lavelle]

Logical operators return a std_ulogic if their inputs are std_ulogic.
Comparisions return boolean. How do I mix these?

Logical operators on std_ulogics are user-defined, and return whatever
you want them to; even a boolean.

...
if D_sel and Addr ?= X"A5A5" then

end if ;
end process ;

What in the strong typing do you believe was broken?

Is D_sel a std_ulogic and the result of the comparison a boolean?
std_ulogic is a user-defined enumeration type composed of arbitrary
character literals. Boolean is a predefined enumeration type. Are you
also saying that that the predefined 'and' operator will now carry out
an operation between a user-defined enumeration and a boolean, and
will return a boolean? If so, how can you *possibly* state that strong
typing has not been broken? It's broken; period.

What has happened is overloading is now present in the context
of a conditional.

This statement makes no sense. To be more precise, you are suggesting
that the analyser must determine the context of every expression, and
use that context to determine what type the operands can be, and what
the return type can be. I've pointed this out before, and you provided
no justification.

As I've also pointed out before there is, I think, a rigorous fix,
which involves introducing a new type into the language. Again, I'd be
interested to hear why you think this doesn't work.

of a conditional. Also some new comparison operators were added
(?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
Note that the top level of a conditional must
evaluate to either boolean, bit, or std_ulogic then a conversion

Have you promoted std_ulogic from a user-defined type to a built-in
type? Is std_ulogic now described in the LRM? If not, you can't do any
of this.

Evan

 

[Jim Lewis]

Evan,

Is D_sel a std_ulogic and the result of the comparison a boolean?

Nope. The comparison uses the new operators, ?=, ?/=, ?>, ?>=, ?<, ?<=,
that return bit and std_ulogic (via overloading in appropriate packages).

std_ulogic is a user-defined enumeration type composed of arbitrary
character literals. Boolean is a predefined enumeration type. Are you
also saying that that the predefined 'and' operator will now carry out
an operation between a user-defined enumeration and a boolean, and
will return a boolean? Nope.

If so, how can you *possibly* state that strong
typing has not been broken? It's broken; period.

Well designed overloading is an essential part of strongly typed
language. Both numeric_std and std_logic_arith allow the following:

Y_Signed <= A_Signed + B_int ;

Does this break strong typing?

This statement makes no sense. To be more precise, you are suggesting
that the analyser must determine the context of every expression, and
use that context to determine what type the operands can be, and what
the return type can be. I've pointed this out before, and you provided
no justification.

The overloading only gets applied at the top level of a condition,
so the analyzer is not looking at every expression.

The overloading is not arbitrary, there is a condition operator, "??",
that is overloaded in the standard packages for bit and std_ulogic.
Given that simulation vendors optimize standard packages, I would
expect this to work just like they were built-in to the syntax of
condition. While one could further overload "??", bit and
std_ulogic are the only ones I plan on using.

BTW, this is not a language proposal, these features are already part
of Accellera VHDL-2006 standard 3.0, so if you join the Accellera VHDL
TSC (which you can do as a non-accellera member), you can download the
standard and read the details. This feature has been designed and
reviewed by people who understand the working of the analyzer much
better than myself.

As I've also pointed out before there is, I think, a rigorous fix,
which involves introducing a new type into the language. Again, I'd be
interested to hear why you think this doesn't work.

Why introduce a new type when the current solution works just fine
with types that we have already made friends with? Besides the
current solution is in the current Accellera standard and is being
implemented by vendors.

Have you promoted std_ulogic from a user-defined type to a built-in
type? Is std_ulogic now described in the LRM?

Yes. ?=, ?/=, ?>, ?>=, ?<, ?<= are pre-defined in
the LRM for types bit and std_ulogic.

?=, ?/= are defined for any one dimensional array type whose
element type is BIT, BOOLEAN or a subtype of STD_ULOGIC.

Note for array types, the operators, ?>, ?>=, ?<, and ?<=, must
be overloaded - hence - if you only use std_logic_1164, you do
not have any implicit ordering comparison operators to worry
about. With vhdl-87 comparisons, the following is true:
Y_bool <= std_logic_vector'("10") > std_logic_vector'("0100") ;

With the ordering comparison operators the following is an error,
unless you have referenced a package that explicitly defines "?>"
(such as numeric_std_unsigned):

If not, you can't do any of this.

Actually all the LRM only needs to define the operators for
some type, such as bit, and then it can overload it separately for
std_ulogic.


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

 

[Evan Lavelle]

The details of this argument depend very much on the extent to which
std_ulogic is now part of the base language, and on the extent to
which all this is implemented by overloading. I don't know these
details, so I'll have to pass. It certainly appears to me, from what
I've read here, that either nothing has been achieved beyond what we
can already achieve by overloading, or that strong typing has been
broken. If I can indeed write "if(Y_stdulogic)" then it's self-evident
that strong typing has been broken.

Well designed overloading is an essential part of strongly typed
language. Both numeric_std and std_logic_arith allow the following:

Y_Signed <= A_Signed + B_int ;

Does this break strong typing?

No, because 'signed' is a user-defined type, and the packages are also
user-defined. If you'd instead asked 'Does 'Y_bool <= A_int + b_bool'
break strong typing, without the use of user-defined overloading, then
my answer would have been 'yes'. The user-extensibility of VHDL gives
us a 'get out of jail free' card. The base language does not give you
this; that is the nature of strong typing. If you disagree, then I'd
like to hear your definition of 'strong typing'.

The overloading only gets applied at the top level of a condition,
so the analyzer is not looking at every expression.

Speaking with my compiler-writer hat on, I would say that an analyser
is not likely to work the way that your statement implies. The
proposed extension means that the value of an object depends on the
context of that object. The value of an object is required when
analysing most of an AST. It is unlikely that a compiler writer would
start from the top of an AST, find every conditional expression, and
descend down to modify the value of the object required by the
conditional. It's much more practical, IMO at least, to carry out
normal analysis, to look back up the AST to determine the context of
the current object, and to modify its value accordingly. In other
words, the compiler will have to look at every expression to handle
this kludge.

BTW, this is not a language proposal, these features are already part
of Accellera VHDL-2006 standard 3.0, so if you join the Accellera VHDL
TSC (which you can do as a non-accellera member), you can download the
standard and read the details.

I was under the impression that the IEEE still owns the copyright on
the LRM; there is, I think, no "Accellera VHDL-2006". However, given
the current state of IEEE-SA, I have no doubt that you'll get your
way, whether or not it makes sense.

Evan

 

[Jim Lewis]

Evan,

I was under the impression that the IEEE still
owns the copyright on the LRM;

Yes, but ...
Accellera VHDL TSC and IEEE VASG have a message of understanding
under which the Accellera VHDL TSC has been granted the right
to make revisions of the standard. Feel free to check out the
VASG webpage:
http://www.eda-stds.org/vasg/

You will note that this was announced on the VHDL-200X reflector:
http://www.eda.org/vhdl-200x/hm/0885.html

there is, I think, no "Accellera VHDL-2006".

You will find the Accellera press release at:
http://www.accellera.org/pressroom/2006/AccelleraVHDL100906.pdf


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]

conditional extensions the following is also legal:
process (all)
begin
...
if D_sel and Addr ?= X"A5A5" then

end if ;
end process ;

What in the strong typing do you believe was broken?
What has happened is overloading is now present in the context
of a conditional. Also some new comparison operators were added
(?=, ?/=, ?>, ?>=, ?<, ?<=) that return bit and std_ulogic values.
Note that the top level of a conditional must
evaluate to either boolean, bit, or std_ulogic then a conversion
is applied - note that there is no generalized implicit conversion
that converts boolean to bit or std_ulogic, or vice-versa.

Jim,

I'm confused. Does the statement

if D_sel and Addr ?= X"A5A5" then

evaluate to a 'yes/no' decision or not? Does

if D_sel then

evaluate to a 'yes/no' decision (D_sel being a std_ulogic)? If yes for
either of these then how? If this is valid then what path is taken if
'D_sel' is unknown? The 'yes' path or the 'no' path? Why?

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

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

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. If this is the case,
then it seems to be a poor reason for weakening the strong typing. The
alternative would be that conditionals 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;

And I'm pretty sure that you're not proposing this kind of change to the
'if' statement.

KJ