Clock Edge notation

[Ben Jones]

"Evan Lavelle" <eml@nospam.uk> wrote in message
news:tf4mk2hmgb39404gsvfqc9atl4r1dcs7fe@4ax.com...

On Tue, 31 Oct 2006 15:28:19 -0800, Jim Lewis <Jim@SynthWorks.com
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-

 

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

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

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

 

[canadianJaouk]

Check out opencores.org, they have a complete SPDIF tranciever with
documentation and test bench

http://www.opencores.org/projects.cgi/web/spdif_interface/overview



aravind wrote:

Hi
Im planning to design an SPDIF receiver for implementation on
Spartan 3 FPGA , But im not sure how to go about the design,Does any
one have ideas ?
Thank u

 

[Evan Lavelle]

On Fri, 03 Nov 2006 08:49:56 -0800, Jim Lewis <Jim@SynthWorks.com>
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]

On Mon, 06 Nov 2006 11:13:19 +0000, Evan Lavelle <eml@nospam.uk>
wrote:

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,

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.

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.

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

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

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

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

 

[Andy]

Jim Lewis wrote:

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

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

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

 

[khanh]

john Doef wrote:

khanh a écrit :

Anybody know a good cross reference software for VHDL ? I have found
some for C/C++, but not many for VHDL language.
I don't know what you mean exactly by 'good cross reference software',
but the free ghdl tool
has a cross reference feature.
See ghdl.free.fr and http://ghdl.free.fr/dlx/dlx_test_behaviour.28.html
for an example.

JD.

What I mean is some software tools, which allows me to view the tree
structure of my VHDL source codes e.g. linkage between top-blocks,
sub-blocks, packages and so forth.

Thanks,

Khanh

 

[Jim Lewis]

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.

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: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:12kvc16q3821c23@corp.supernews.com...

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]

On Mon, 06 Nov 2006 13:59:02 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

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,

What in the strong typing do you believe was broken?

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?

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.

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.

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?

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):
Y_bool <= std_logic_vector'("10") ?> std_logic_vector'("0100") ;

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

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

 

[homoalteraiensis]

i am about to do this for altera cyclone to adapt to my studio devices
- but would also be interested in exchanging knowledge about xilinx
environment.

 

[wallge]

emacs with the LISP vhdl-mode plugin will (kind-of) do this
plus emacs with the plugin is the best VHDL editor in my opinion...


khanh wrote:

john Doef wrote:
khanh a écrit :

Anybody know a good cross reference software for VHDL ? I have found
some for C/C++, but not many for VHDL language.
I don't know what you mean exactly by 'good cross reference software',
but the free ghdl tool
has a cross reference feature.
See ghdl.free.fr and http://ghdl.free.fr/dlx/dlx_test_behaviour.28.html
for an example.

JD.

What I mean is some software tools, which allows me to view the tree
structure of my VHDL source codes e.g. linkage between top-blocks,
sub-blocks, packages and so forth.

Thanks,

Khanh

 

[Evan Lavelle]

On Tue, 07 Nov 2006 10:26:13 -0800, Jim Lewis <Jim@SynthWorks.com>
wrote:

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.

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

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.

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: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:12kvc16q3821c23@corp.supernews.com...
<snip> 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.

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

 

[james]

On Sun, 12 Nov 2006 06:19:50 -0800, "ec" <wavesoft@netvision.net.il>
wrote:

+++Hi All
+++
+++Is VHDL just for qualified emgimeers ?
+++
+++I am a old elect. techition with alot of experince and knowledge.
+++
+++I want to get into VHDL based designing.
+++
+++What are my theoretical chances ?
+++Thanks
+++ec
+++
***********

Based on your typing skills, you are going to spend a huge amount of
time debugging the syntax errors that should abound in your code.

Other than that a cave man can learn VHDL.


james

 

[Jonathan Bromley]

On Mon, 13 Nov 2006 23:35:02 GMT, james
<george@washington.edu> wrote:

[...]

Other than that a cave man can learn VHDL.

Ug.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Hans]

<burn.sir@gmail.com> wrote in message
news:1162405707.070808.217990@m73g2000cwd.googlegroups.com...

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