Null statement in VHDL

[Weng Tianxiang]

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

 

[Mike Treseler]

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

 

[Weng Tianxiang]

They sometimes make a nice placeholder for a comment:

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


Yes. What's the question?


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

 

[Mike Treseler]

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

 

[Mike Lundy]

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.

 

[Weng Tianxiang]

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

 

[Alex Colvin]

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.

 

[Andy]

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

 

[Andy]

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

 

[Mike Lundy]

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

 

[comp.arch.fpga]

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.

The frustrating thing is, that there are papers out there that show
how simple
it is to greatly expanded the synthesizable subset.

Some examples:

The following code can be made synthesizable by a simple vhdl->vhdl
transformation. A preprocessor would suffice:
if rising_edge(clk) and enable='1' then ...

Why is there only a single wait statement allowed per process? If all
wait statements depend on the same clock signal it is relativly easy
to automatically create a state machine with one state per wait
statement.

What is so hard about replacing "/" by a division circuit? Especially
for a tool that is
delivered with a core generator that supports division? Especially for
division by a constant (can be implemented by a multiplier, yet
multiplication is supported)?

At least most tools now recognize initialization values for signals.
Took them only 20 years to implement that.


My frustration comes from work in the EDA software field. I see that
really hard tasks that are solved successfully during the synthesis
and implementation process and wonder why topics like those above or
not handled well, even though they are a lot simpler.

Kolja Sulimma

 

[HT-Lab]

The frustrating thing is, that there are papers out there that show
how simple
it is to greatly expanded the synthesizable subset.

Some examples:

The following code can be made synthesizable by a simple vhdl->vhdl
transformation. A preprocessor would suffice:
if rising_edge(clk) and enable='1' then ...

Gated clocks are supported by most high-end synthesis tools.

Why is there only a single wait statement allowed per process? If all
wait statements depend on the same clock signal it is relativly easy
to automatically create a state machine with one state per wait
statement.

Precision supports multiple wait statement per process provided, as you
mention they use the same clock, from the manual:

"Multiple wait statements are supported in a process with some synthesis
restrictions. All the control paths should have at least one wait statement
and all of the wait statements should be identical with a single bit clock
expression.

The expression in the until condition must specify a leading or falling
single clock edge. All assignments inside the process result in the creation
of registers. Each register (flip-flop) is clocked with the single clock
signal.

There are a number of cases where multiple waits are synthesizable and
resemble statemachine behavior. In Precision RTL Synthesis, multiple waits
are supported".

process -- no sensitivity list
begin
wait until clk' event AND clk='1';
output_signal <= 0;
while (input_signal < 6) loop
wait until clk' event AND clk='1';
output_signal <= output_signal +1;
end loop;
end process;

What is so hard about replacing "/" by a division circuit? Especially
for a tool that is
delivered with a core generator that supports division? Especially for
division by a constant (can be implemented by a multiplier, yet
multiplication is supported)?

I agree, not sure what the reason is.

At least most tools now recognize initialization values for signals.
Took them only 20 years to implement that.

This might work for Xilinx which can initialise a register from the
bitstream, however, what would happen if you use this design on a ASIC or
FPGA that doesn't support this (e.g. Actel). I am all in favour of
technology independent code and inferring as much as possible, makes life so
much easier for the next guy to pick up your code

Hans
www.ht-lab.com

 

[comp.arch.fpga]

This might work for Xilinx which can initialise a register from the
bitstream, however, what would happen if you use this design on a ASIC or
FPGA that doesn't support this (e.g. Actel). I am all in favour of
technology independent code and inferring as much as possible, makes life so
much easier for the next guy to pick up your code

I believe that's similar to instantiating 10 millon gates in a device
that only supports
5 million gates or stating a 500MHz constraint when only 250 are
possible.
The tool should tell you the reason why it can't be done.

Excludig a feature because a small portion of technologies can't
support it is not wise.
Especially in a case like the reset values were you get a simulation
mismatch because of
the omission.

Kolja Sulimma

 

[Colin Paul Gloster]

|------------------------------------------------------------------------|
|"[..] |
| |
|> I have two questions: |
|> 1. Based on my experiences with VHDL, the following 3 designs should |
|> be the same. |
| |
|Yes. [..] |
| |
|[..]" |
|------------------------------------------------------------------------|

I disagree.

A2 is equivalent to A3.

A1 and A2 could be equivalent, but not necessarily. In A1, State_A has
the value State_0_S and is assigned the value it already has. Instead
of that assignment, A2 has a null statement. However, A1 is not
necessarily equivalent to A2 if:
A2 could be running with another process which is assigning any other
value to State_A;
or
the assignment State_A <= State_0_S; could delete previously computed
transactions from the projected output waveform.

Regards,
Colin Paul Gloster

 

[Colin Paul Gloster]

I apologize if almost the same response as this is received. I had
typed a response which I thought I posted over an hour ago but it does
not seem to appear even on the server I originally had posted it on,
so I retype a response and I try a different client and server.

In timestamped Tue, 28 Aug 2007 07:45:18 -0000,
"comp.arch.fpga" <[email protected]> posted:
|----------------------------------------------------------------------------|
|"[..] |
| |
|At least most tools now recognize initialization values for signals." |
|----------------------------------------------------------------------------|

Synopsys Presto VHDL does not, according to what is documented on Page
C-5 of
sold/doc/online/dc/pvhdl/pvhdl_c.pdf
for Version Y-2006.06. Which synthesis tools do support initialization
of signals?

|----------------------------------------------------------------------------|
|"Took them only 20 years to implement that. |
| |
| |
|My frustration comes from work in the EDA software field. I see that |
|really hard tasks that are solved successfully during the synthesis |
|and implementation process and wonder why topics like those above or |
|not handled well, even though they are a lot simpler. |
| |
|Kolja Sulimma" |
|----------------------------------------------------------------------------|

Perhaps because they are too lazy to implement features which
customers can easily be led to believe are frills? E.g. Jonathan
Bromley posted on 2007 March 5th:
"[..]

[..] The majority of
hardware platforms do not offer reliable power-up
initialisation of internal state. Consequently it is appropriate
to code explicitly some reset behaviour. For exactly this
reason, the hardware-oriented data types in VHDL (std_logic,
etc) have a specific undefined value as the leftmost value
of their value-set, so that initialisation oversights are
more likely to be detected.


Unfortunately for a purist such as you, there are many
occasions in hardware design where it is entirely
appropriate to read an uninitialised object. For
example, a pipeline or shift register probably does
not need the hardware overhead of reset; it will
automatically flush itself out over the first few clock
cycles - but only if you allow it to run, which of course
entails reading uninitialised (or default-initialised) values.
Consequently it is appropriate for synthesis tools to do
pretty much what they generally do: don't worry about
initialisations. For preference, they should issue warnings
about attempts to do explicit initialisation, since these cannot
be synthesised to hardware on most platforms. However,
even then it may be appropriate to let this past, since the
explicit initialisation may be useful in order to limit the
excessive pessimism that usually occurs when a simulator
is confronted with a lot of 'U' or 'X' values. This issue is
one of those things that hardware designers are required
to be aware of, and failure to attend to it is usually a good
identifying mark of a beginner, or a dyed-in-the-wool
programmer assuming that hardware design is easy.

[..]"

Regards,
Colin Paul Gloster

 

[Tricky]

States A2 and A3 will function exactly the same, but A1 will be
different. If you monitered State_A'transaction in a simulator you'd
get a response on every clock cycle with A1, but only when A='1' for
A2 and 3. It may mean the difference between synthesizing a register
with an enable (in the case of A2 and A3) and without (A1).

the null statement can be very useful for specifically ignoring
certain cases.

 

[comp.arch.fpga]

Perhaps because they are too lazy to implement features which
customers can easily be led to believe are frills?

I would say that they do not question decisions that were made by
synopsys 20 years ago.

E.g. Jonathan
Bromley posted on 2007 March 5th:

Hmm. I just have to counter that post here.

[..] The majority of
hardware platforms do not offer reliable power-up
initialisation of internal state.

True. But the vast majority of design starts are on platforms that do
support it.

Consequently it is appropriate
to code explicitly some reset behaviour.

At extra hardware cost on my platform.

For exactly this
reason, the hardware-oriented data types in VHDL (std_logic,
etc) have a specific undefined value as the leftmost value
of their value-set, so that initialisation oversights are
more likely to be detected.

So, when I explicitly assign an initial value of '1' and then start
synthesis for a platform that supports initial values the synthesis
tool
should synthesize to an initial value of '0'? How does that detect
initialization oversight?
It is an implementation error. Plain and simple.

Leaving the initial value unassigned makes formal verification a PITA.

This issue is
one of those things that hardware designers are required
to be aware of,

Surely the OP meant "ASIC designres".

and failure to attend to it is usually a good
identifying mark of a beginner, or a dyed-in-the-wool
programmer assuming that hardware design is easy.

Well it isn't. But it could if tools would catch up. We spend easily
25% of the design time
of the last project debugging the tools.
(Deciphering such great synthesis guidelines as the statement that
arrays should not be used.
Instead std_logic_vector should be used. But that is an array. Hmm.)

Kolja Sulimma

 

[Jim Lewis]

Andy and Mike,
I think the status-quo is more complex than you state.
Vendors don't implement standards just because just because they
have neat features. It is about marketing and investing. A vendor
invests in features that will make them money and/or differentiate
their software from a competitors.

If you want change, you need to focus on communicating to them what
features you require. They listen best to the people with $$$, so
you may wish to file bug reports with both your vendor and with the
person paying for the tools (or at least let the person paying for
tools know about open bugs on a regular basis). Short of this,
we would all have to pool together and talk to them collectively.

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

Actually most big players did not participate. At the time there
were concerns with loosing patents due to standards participation.

The theory behind the minimum was so a IP supplier would have a
standard to claim compliance to. The second standard actually was
started as soon as the first one was done, so I still believe it
was the best decision.

Since then, updates to the standard have been few and far between,

The first revision was 1076.6-1999 and 1076.6-2004.
While that is slow, standards are a volunteer effort.
You get what you invest. We need more user companies
who are interested in this to invest the time.

> and the standard has also migrated from a template based approach,
> to a behavioral approach.

An idea put forward by tool vendors. At the time it seemed to be
a good way to avoid having a huge set of templates and leaving a
few critical ones behind.

At this point, the standard is due for revision by 2009.
Since vendors have not implemented all of it, it would be
an opportune time to change the approach if it is appropriate
to do so. Myself, I am tied up with the general language revision,
however, it is a good "starter" place for participating in standards.
Particularly for experienced designers who regularly voice an
opinion here (like Andy J, Mike T, Jon B, KJ, ... not meaning to leave
any interested party out).

Quit bitching, get the vendors involved and make it a standard
you can live with and a standard the vendors will implement.

Cheers,
Jim

 

[Andy]

States A2 and A3 will function exactly the same, but A1 will be
different. If you monitered State_A'transaction in a simulator you'd
get a response on every clock cycle with A1, but only when A='1' for
A2 and 3. It may mean the difference between synthesizing a register
with an enable (in the case of A2 and A3) and without (A1).

the null statement can be very useful for specifically ignoring
certain cases.

I agree, the null statement is usually built-in documentation that
says either "I haven't gotten that far yet" or "Yes I did consider
this, and am not doing anything here". Sometimes (i.e. case
statements) it is necessary for completeness.

Andy

 

[Jonathan Bromley]

E.g. Jonathan Bromley posted on 2007 March 5th:

Hmm. I just have to counter that post here.

[..] The majority of
hardware platforms do not offer reliable power-up
initialisation of internal state.

True. But the vast majority of design starts are on platforms that do
support it.

I have spoken with forked tongue....

You may recall that a while ago I had a dispute about this
with Rob Dekker of Verific (a software company whose prime
product is an HDL front-end, used by many vendors of synthesis,
formal and linting tools): see the thread

Coding style, wait statement, sensitivity list and synthesis.

in comp.lang.vhdl around January 2006. I tried there to
argue that synthesis front-ends should support any construct
that maps to physically realisable hardware, and the back-end
(mapper) should error-out if the specific target does not
support the necessary features. I still think I was right,
but I don't think my arguments prevailed. So I have reverted
to my standard, conservative position that synthesis users
should restrict themselves to a lowest-common-denominator
style. I make a few exceptions: for example, there are
still synthesis tools around (at least, there were the
last time I checked) that won't tolerate Verilog
with a mixture of blocking and nonblocking assignments,
thereby making it impossible to emulate VHDL variables
in Verilog. That is so laughably stupid that I'm prepared
to tell people not to use such tools. But support for
initialization is still restricted to a small subset
of the available tools, so I can't reasonably recommend
it except to Xilinx- or Altera-specific users.

My conservative position must not be taken as an argument
that we shouldn't try to move forward. Basically I agree
with everything Kolja has said; it's just that I am obliged
to help people to make the best of what they have today -
and sometimes those people need to write highly portable code.
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

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