Null statement in VHDL
 

Hi,
I rarely use null statement in my designs.

I check the definition of null statement from book "HDL Chip Design"
written by Douglas J. Smith. It says that "Performs no action. Has no
other effect other than to pass execution on to the next sequential
statement."

I have two questions:
1. Based on my experiences with VHDL, the following 3 designs should
be the same.

State_A is a state machine signal.

A1 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
else
State_A <= State_0_S;
end if;
...
...
end case;
end if;
end process;

A2 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
else
null;
end if;
...
...
end case;
end if;
end process;

A3 : process(RESET, CLK)
begin
if(RESET = '1') then
State_A <= State_0_S;
elsif(CLK'event and CLK = '1') then
case State_A is
when State_0_S =>
if(A = '1') then
State_A <= State_1_S;
end if;
...
...
end case;
end if;
end process;

2. Where can I download the latest version of VHDL language definition
(83, 90 2000)?

Any comments are welcome.

Thank you.

Weng

Re: Null statement in VHDL
 

Weng Tianxiang wrote:

> I rarely use null statement in my designs.

They sometimes make a nice placeholder for a comment:

...
else
null; -- future: enable explosive bolts here.
end if;

> I have two questions:
> 1. Based on my experiences with VHDL, the following 3 designs should
> be the same.

Yes. What's the question?

> 2. Where can I download the latest version of VHDL language definition
> (83, 90 2000)?

http://www.ieee.org/web/standards/home/index.html

-- Mike Treseler

Re: Null statement in VHDL
 

On Aug 27, 10:37 am, Mike Treseler <mike_trese...@comcast.net> wrote:
> Weng Tianxiang wrote:
> > I rarely use null statement in my designs.
>
> They sometimes make a nice placeholder for a comment:
>
> ...
> else
> null; -- future: enable explosive bolts here.
> end if;
>
> > I have two questions:
> > 1. Based on my experiences with VHDL, the following 3 designs should
> > be the same.
>
> Yes. What's the question?
>
> > 2. Where can I download the latest version of VHDL language definition
> > (83, 90 2000)?
>
> http://www.ieee.org/web/standards/home/index.html
>
> -- Mike Treseler

Hi Mike,
Thank you.

It seems to me that I should buy a VHDL standard book (I've never have
it).

93 or 2000 or 2002? Any suggestions?

Weng

Re: Null statement in VHDL
 

Weng Tianxiang wrote:

> It seems to me that I should buy a VHDL standard book (I've never have
> it).
>
> 93 or 2000 or 2002? Any suggestions?

Get the latest available, but
I would get a copy of Ashenden,
a good vhdl simulator,
and master those first.

-- Mike Treseler

Re: Null statement in VHDL
 

> It seems to me that I should buy a VHDL standard book (I've never have
> it).
>
> 93 or 2000 or 2002? Any suggestions?

This is going to sound awful, but I'd actually recommend for your
mental health that you not look too deeply at the actual standards.
Instead, read about the synthesizers themselves. None of the VHDL
synthesizers I've tried completely implement any version of the
standard. Instead, they implement odd hybrids of the different
versions of the standard, on the grounds that "no one uses this
feature" (well, of course! No one uses it because it doesn't work in
your popular product!)

I get really frustrated when I try to implement something using
standard VHDL and find that it is incorrectly or incompletely
supported. I wish more people would have higher standards with the
software they use. The way I see it, it's false advertising to
advertise something as a VHDL synthesizer if it doesn't completely
implement the VHDL standard, but not many seem to agree with me.

I think it comes down to the difference between engineers and
scientists. Scientists prefer theory, and deviations from the ideal
grate on us. Engineers prefer practicality, and will tend to solder on
(pun intended) through crappy software, more interested in the end
result than the process. I have grounding in both, so I complain as I
implement, and depend less on crappy software whenever the chance
presents itself. Life's too short for bad software.

Re: Null statement in VHDL
 

On Aug 27, 11:33 am, Mike Lundy <novas0...@gmail.com> wrote:
> > It seems to me that I should buy a VHDL standard book (I've never have
> > it).
>
> > 93 or 2000 or 2002? Any suggestions?
>
> This is going to sound awful, but I'd actually recommend for your
> mental health that you not look too deeply at the actual standards.
> Instead, read about the synthesizers themselves. None of the VHDL
> synthesizers I've tried completely implement any version of the
> standard. Instead, they implement odd hybrids of the different
> versions of the standard, on the grounds that "no one uses this
> feature" (well, of course! No one uses it because it doesn't work in
> your popular product!)
>
> I get really frustrated when I try to implement something using
> standard VHDL and find that it is incorrectly or incompletely
> supported. I wish more people would have higher standards with the
> software they use. The way I see it, it's false advertising to
> advertise something as a VHDL synthesizer if it doesn't completely
> implement the VHDL standard, but not many seem to agree with me.
>
> I think it comes down to the difference between engineers and
> scientists. Scientists prefer theory, and deviations from the ideal
> grate on us. Engineers prefer practicality, and will tend to solder on
> (pun intended) through crappy software, more interested in the end
> result than the process. I have grounding in both, so I complain as I
> implement, and depend less on crappy software whenever the chance
> presents itself. Life's too short for bad software.

Hi Mike,
"None of the VHDL
synthesizers I've tried completely implement any version of the
standard. Instead, they implement odd hybrids of the different
versions of the standard"

Your comments are interesting and funny !!!

There are a lot of definitions I have difficulty to learn so that I
have never used them and have never tried them.

For example, sharing a signal, block concept and the latest ones that
do formal verification are a few features I have never used and tried.

I prefer using a very small set of the definitions and the strategy
works well.

One thing I miss a lot is 'orif' keyword compared to 'elsif'.

'orif' introduces a group of conditions that are mutually exclusive.

On any output buses or input buses, all data running on the buses are
mutually exclusive.

I couldn't persuade James to change his mind.

Weng

Re: Null statement in VHDL
 

>It seems to me that I should buy a VHDL standard book (I've never have
>it).

>93 or 2000 or 2002? Any suggestions?

whichever standard (or mix thereof) is supported by the software you
expect to use. just because it's in the book doesn't mean it works.

--
mac the naïf

Re: Null statement in VHDL
 

On Aug 27, 1:33 pm, Mike Lundy <novas0...@gmail.com> wrote:
> > It seems to me that I should buy a VHDL standard book (I've never have
> > it).
>
> > 93 or 2000 or 2002? Any suggestions?
>
> This is going to sound awful, but I'd actually recommend for your
> mental health that you not look too deeply at the actual standards.
> Instead, read about the synthesizers themselves. None of the VHDL
> synthesizers I've tried completely implement any version of the
> standard. Instead, they implement odd hybrids of the different
> versions of the standard, on the grounds that "no one uses this
> feature" (well, of course! No one uses it because it doesn't work in
> your popular product!)
>
> I get really frustrated when I try to implement something using
> standard VHDL and find that it is incorrectly or incompletely
> supported. I wish more people would have higher standards with the
> software they use. The way I see it, it's false advertising to
> advertise something as a VHDL synthesizer if it doesn't completely
> implement the VHDL standard, but not many seem to agree with me.
>
> I think it comes down to the difference between engineers and
> scientists. Scientists prefer theory, and deviations from the ideal
> grate on us. Engineers prefer practicality, and will tend to solder on
> (pun intended) through crappy software, more interested in the end
> result than the process. I have grounding in both, so I complain as I
> implement, and depend less on crappy software whenever the chance
> presents itself. Life's too short for bad software.

Mike,

I share your frustrations, but with a little common sense, most
limitations of synthesis are understandable. For instance, time delays
(independent of a clock, i.e. "after 5 ns") are meaningless to most
synthesizable targets, because there is no ability to accurately
implement them. File IO is another (although pre-elaboration level
file IO, e.g. using a file to initialize a constant, should be allowed
but is not). After all, vhdl is a technology-independent, descriptive
language; naturally, there will be some aspects of the language that
do not map to certain technology targets.

Then there are things like no deferred constants in synthesis still
bother me, because there is no good reason for the limitation. Most
synthesis tools do not support global signals either.

There is an ieee standard for the "minimum" synthesizable subset of
vhdl, but its creation was dominated by the big player(s) in
synthesis, and focused on what they had already implemented. Since
then, updates to the standard have been few and far between, and the
standard has also migrated from a template based approach, to a
behavioral approach. The tool vendors (some more responsive than
others to customer's needs) have since implemented parts of vhdl not
handled in the synthesis standard. In some ways, this accelerates the
adoption of new features (due to competition), but it also leads to
diversity of capabilities across vendors, requiring a minimum "least
common denominator" approach to coding for multiple synthesis vendors.
The only way to raise the least common denominator is by refusing to
buy/use products that fail to keep up with the competition (so they
fall out of the business, like synopsys fpga synthesis), or revising
the standards (and refusing to buy/use products that don't adhere to
the standard). Since both require market response, the standards
effort is less meaningful, and has lapsed behind.

Andy

Re: Null statement in VHDL
 

On Aug 27, 2:32 pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Aug 27, 11:33 am, Mike Lundy <novas0...@gmail.com> wrote:
>
>
>
> > > It seems to me that I should buy a VHDL standard book (I've never have
> > > it).
>
> > > 93 or 2000 or 2002? Any suggestions?
>
> > This is going to sound awful, but I'd actually recommend for your
> > mental health that you not look too deeply at the actual standards.
> > Instead, read about the synthesizers themselves. None of the VHDL
> > synthesizers I've tried completely implement any version of the
> > standard. Instead, they implement odd hybrids of the different
> > versions of the standard, on the grounds that "no one uses this
> > feature" (well, of course! No one uses it because it doesn't work in
> > your popular product!)
>
> > I get really frustrated when I try to implement something using
> > standard VHDL and find that it is incorrectly or incompletely
> > supported. I wish more people would have higher standards with the
> > software they use. The way I see it, it's false advertising to
> > advertise something as a VHDL synthesizer if it doesn't completely
> > implement the VHDL standard, but not many seem to agree with me.
>
> > I think it comes down to the difference between engineers and
> > scientists. Scientists prefer theory, and deviations from the ideal
> > grate on us. Engineers prefer practicality, and will tend to solder on
> > (pun intended) through crappy software, more interested in the end
> > result than the process. I have grounding in both, so I complain as I
> > implement, and depend less on crappy software whenever the chance
> > presents itself. Life's too short for bad software.
>
> Hi Mike,
> "None of the VHDL
> synthesizers I've tried completely implement any version of the
> standard. Instead, they implement odd hybrids of the different
> versions of the standard"
>
> Your comments are interesting and funny !!!
>
> There are a lot of definitions I have difficulty to learn so that I
> have never used them and have never tried them.
>
> For example, sharing a signal, block concept and the latest ones that
> do formal verification are a few features I have never used and tried.
>
> I prefer using a very small set of the definitions and the strategy
> works well.
>
> One thing I miss a lot is 'orif' keyword compared to 'elsif'.
>
> 'orif' introduces a group of conditions that are mutually exclusive.
>
> On any output buses or input buses, all data running on the buses are
> mutually exclusive.
>
> I couldn't persuade James to change his mind.
>
> Weng

Weng,

What would happen in a simulator if the "orif" conditions were not
actually mutually exclusive? How would you allow the user to define
said behavior? Is zero-hot and option, or is one-hot guaranteed? How
would the user define that?

The existing language allows for mutually exclusive conditions, but
said conditions must be statically verifiable as mutex and complete
(case statements). For dynamic mutex inputs, verification is best
handled in an assertion. If a standardized one_hot() or zero_one_hot()
function could be created (to operate on an unconstrained vector of
booleans, for example), then synthesis could recognize their use in an
assertion, and make the appropriate optimizations automatically,
without affecting the syntax or structure of the language. The
assertion (or other code) could also control what happens when, in
fact, the conditions are not mutually exclusive (the same way the
language handles indices out of bounds, etc.). In other words, in
order to gain that level of control over what happens if mutex is not
true, you'd have to use the same amount of code for either solution,
and the latter solution does not require a change to the language.
Additionally, the use of an assertion is such an application allows
the code more flexibility in describing the resulting behavior,
without resulting to a single if-orif tree. Simply tell the synthesis
tool that, by the way, x and y are one_hot, and it can make
optimizations (like sharing resources) efficiently, independent of the
rest of the structure.

Finally, "orif" would be a very poor choice for such a keyword, even
if the feature were a good idea. "Orif" by name implies that multiple
conditions are potentially true (logical 'OR' function), and all
statements associated with all true conditions would be executed,
which is precisely the opposite of what you described. This behavior
is equivalent to multiple, non-nested if-then statements.

Andy

Re: Null statement in VHDL
 

On Aug 27, 3:09 pm, Andy <jonesa...@comcast.net> wrote:
> Mike,
>
> I share your frustrations, but with a little common sense, most
> limitations of synthesis are understandable. For instance, time delays
> (independent of a clock, i.e. "after 5 ns") are meaningless to most
> synthesizable targets, because there is no ability to accurately
> implement them. File IO is another (although pre-elaboration level
> file IO, e.g. using a file to initialize a constant, should be allowed
> but is not). After all, vhdl is a technology-independent, descriptive
> language; naturally, there will be some aspects of the language that
> do not map to certain technology targets.

All true, but remember, I'm complaining about difference between the
standard and what companies implement, not the vhdl standard itself.
The differences between synthesis and simulation modes (while a tad
murky in the standard itself) are perfectly understandable, given both
the nature of the output, and vhdl's history.

A side note: I'm amused by the parallels between Lisp's development
and VHDL's. Both started as documentation formats (... more or less)
that someone decided to write an interpreter for.

> Then there are things like no deferred constants in synthesis still
> bother me, because there is no good reason for the limitation. Most
> synthesis tools do not support global signals either.

Yeah, both of those bug me. It's so difficult to achieve truly
universal constants in a design.

> There is an ieee standard for the "minimum" synthesizable subset of
> vhdl, but its creation was dominated by the big player(s) in
> synthesis, and focused on what they had already implemented. Since
> then, updates to the standard have been few and far between, and the
> standard has also migrated from a template based approach, to a
> behavioral approach. The tool vendors (some more responsive than
> others to customer's needs) have since implemented parts of vhdl not
> handled in the synthesis standard. In some ways, this accelerates the
> adoption of new features (due to competition), but it also leads to
> diversity of capabilities across vendors, requiring a minimum "least
> common denominator" approach to coding for multiple synthesis vendors.
> The only way to raise the least common denominator is by refusing to
> buy/use products that fail to keep up with the competition (so they
> fall out of the business, like synopsys fpga synthesis), or revising
> the standards (and refusing to buy/use products that don't adhere to
> the standard). Since both require market response, the standards
> effort is less meaningful, and has lapsed behind.

That's pretty much my point, yeah. People need to stop allowing
companies to shovel crap. Don't buy it if it's crap. If it only
implements 1/2 of the standard, let's call it a VH synthisizer
instead :P. If you absolutely must buy it (gotta get the product out,
after all, even if you have to compromise your values to do so...)
then raise a huge stink about how bad the software is. Report every
bug you come across. Publicize the worst of them if the vendor still
doesn't fix them. Just don't settle for the status quo.

C compilers eventually came out of the dark ages. It would be
excellent if VHDL synthesizers could do the same.