Null statement in VHDL
Weng Tianxiang
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
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).
>
> 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
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).
>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
Andy
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
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 :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.
comp.arch.fpga
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
"comp.arch.fpga" <ksul...@googlemail.com> wrote in message
news:1188287118.8...@o80g2000hse.googlegroups.com...
> On 28 Aug., 00:09, Andy <jonesa...@comcast.net> wrote:
>> On Aug 27, 1:33 pm, Mike Lundy <novas0...@gmail.com> wrote:
>>
>>
>> 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 ...
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
> "comp.arch.fpga" <ksuli...@googlemail.com> wrote in message
> > 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 :-)
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
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 news:1188287118.8...@o80g2000hse.googlegroups.com
timestamped Tue, 28 Aug 2007 07:45:18 -0000,
"comp.arch.fpga" <ksul...@googlemail.com> 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
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
wrote:
>
> Perhaps because they are too lazy to implement features which
> customers can easily be led to believe are frills?
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
>> From Mike
>> 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.
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
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
<ksul...@googlemail.com> wrote:
>> 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
jonathan...@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.
KJ
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
news:shbmd3pmpmo6sfkqj...@4ax.com...
> On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga"
> <ksul...@googlemail.com> wrote:
>
>
>>> E.g. Jonathan Bromley posted on 2007 March 5th:
> 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,
I don't recall the thread but I totally agree with you.
> 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.
For whatever tools that you have that meet the following two tests, did you
open a service request?
- Tool claims compliance to VHDL standard
- Tool does not error (or at least warning) about ignoring the initial value
assignment
If you did not, then (shame on you) and why not? The way to get tool
vendors to change their tools is to hit them directly with a service request
on their tool. It's not always successful, but I've found that many times
it is in this type of example since they have been called on a particular
area of non-compliance on a tool that they say is compliant to a particular
standard.
> 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.
And publicize against the tools that don't support the language.
KJ
Jonathan Bromley
>For whatever tools that you have that meet the following two tests, did you
>open a service request?
>- Tool claims compliance to VHDL standard
>- Tool does not error (or at least warning) about ignoring the initial value
>assignment
Every synth tool I've used issues a warning or error when it ignores
initial values. It's a tool restriction I've learnt to live with.
On FPGAs with well-defined config values, I work around it by
providing an explicit asynchronous reset in the usual way and then
tying-off that reset to "false" somewhere in the top-level wrapper
that organises the design for the target platform. That gives me
no additional hardware cost in the FPGAs that I've used, and it
gives me a different, clumsier, but equally effective way to
specify initial values.
KJ
"Jonathan Bromley" <jonathan...@MYCOMPANY.com> wrote in message
> On Sun, 02 Sep 2007 22:38:38 GMT, "KJ" wrote:
>
>>For whatever tools that you have that meet the following two tests, did
>>you
>>open a service request?
>>- Tool claims compliance to VHDL standard
>>- Tool does not error (or at least warning) about ignoring the initial
>>value
>>assignment
>
> Every synth tool I've used issues a warning or error when it ignores
> initial values. It's a tool restriction I've learnt to live with.
If the target device does not support initial values then that would be the
correct behaviour of the tool. If the target device does support a power up
value for registers than I still say that the service request should be
opened to the supplier for non-compliance to the VHDL standard.
> On FPGAs with well-defined config values, I work around it by
> providing an explicit asynchronous reset in the usual way and then
> tying-off that reset to "false" somewhere in the top-level wrapper
> that organises the design for the target platform. That gives me
> no additional hardware cost in the FPGAs that I've used, and it
> gives me a different, clumsier, but equally effective way to
> specify initial values.
But that doesn't sound like a 'tool' thing, it sounds like a way to make the
code re-usable when targeted towards devices that either do or not support
power up defined values. I thought your point had to do with grumblings
about synthesis tools but it appears that it really has to do with physical
parts that do not have guaranteed power up values.
KJ
comp.arch.fpga
wrote:
> Every synth tool I've used issues a warning or error when it ignores
> initial values. It's a tool restriction I've learnt to live with.
> On FPGAs with well-defined config values, I work around it by
> providing an explicit asynchronous reset in the usual way and then
> tying-off that reset to "false" somewhere in the top-level wrapper
> that organises the design for the target platform. That gives me
> no additional hardware cost in the FPGAs that I've used, and it
> gives me a different, clumsier, but equally effective way to
> specify initial values.
No it is not. There are two bad things that can happen:
1. Constant propagation is a simple task for logic synthesis. The
reset might be removed from the DFFs
bacause it is not needed.
There is no requirement for the tool to infer the power on value from
the async reset value.
In fact, doing so could violate the spec. If I code a dynamic reset of
'1' and a power up value of '0' the tool must not
set the power up value to '1'. Especially not if it can infer that
there never will be a dynamic reset.
2. If constant propagation on reset nets is prohibited by the tool to
preserve the reset values in the case
you describe your never-used sync reset prevents the use of the sync
reset for logic optimization. The
resulting logic might be more than 50% larger than necessary.
It is more a dirty hack to trick the tools in the desired behaviour
than it is an effective way to specify initial values.
Any tool is free to break your implentation and will still be in
compliance with the language spec.
Kolja Sulimma
Jonathan Bromley
>On 3 Sep., 09:53, Jonathan Bromley wrote:
[an asynch reset, tied false]
>> gives me a different, clumsier, but equally effective way to
>> specify initial values.
>
>No it is not. There are two bad things that can happen:
Agreed with both your points, although my experience
is consistently that those bad things do *not*
happen in practice.
>It is more a dirty hack to trick the tools in the desired behaviour
>than it is an effective way to specify initial values.
>Any tool is free to break your implentation and will still be in
>compliance with the language spec.
Guilty as charged. There's no doubt that synthesis
support for initialization values - with, of course,
checks that it been applied only to variables or
signals that represent a flip-flop - would be the
best solution by far.
Andy
> "Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message
The most often confused part about reset and initial conditions (in
FPGA's, where reliable initial conditions are possible), is that
neither handles the transition from reset or configuration to normal
operation automatically and correctly. However, an explicit reset
gives the user more options to correctly implement the transition.
For example, a counter is initialized/reset to zero, but on the first
clock out of reset (or configuration), the counter counts down,
resulting in a rollover. Unless the reset or end of configuration is
synchronized to the clock, the entire contents of the counter become
undefined. And this problem is not just related to counters. One-hot
state machines can get into illegal states if transitions are allowed
on the first clock out of reset/configuration. In the old days (before
FPGA's and dirt), we used to have rules about down counters being
initialized to odd values, and up counters initialized to even values,
initial transitions on state machines being single bit transitions,
etc. to combat this. These methods are still valid, but are much less
reviewable/auditable/verifiable that correctly handling the timing
relationship between the clock and the end of configuration or reset.
This timing relationship can be handled by traditionally synchronizing
the deassertion of reset, or by delaying the clock sufficiently after
the deassertion of reset/config. The latter is applicable regardless
of whether reset is explicitly coded; the former is applicable only to
explicit resets.
Some FPGA storage elements (e.g. RAM) do not have a reset capability,
but do have an initialization (via configuration) capability. It is
vital that either the clock be disabled sufficiently after
configuration is complete, or that the contents of the ram are not
allowed to change on the first clock after configuration is complete
(assuming one clock period is long enough to guarantee that all
storage elements are out of configuration).
In summary, just because VHDL initial conditions are supported by a
synthesis tool does not mean that all initialization problems are
automatically handled by them.
Andy
Andy
> >It is more a dirty hack to trick the tools in the desired behaviour
> >than it is an effective way to specify initial values.
> >Any tool is free to break your implentation and will still be in
> >compliance with the language spec.
>
> Guilty as charged. There's no doubt that synthesis
> support for initialization values - with, of course,
> checks that it been applied only to variables or
> signals that represent a flip-flop - would be the
> best solution by far.
Why the restriction on variables/signals that represent flops? It
seems to me that initialization of a combinatorial variable or signal
would be correctly simulated and synthesized even if it were just
ignored (thus no warning issued), unless a combinatorial loop/latch
were involved, which would be its own warning.
Besides, variables, in and of themselves, represent neither register
nor combinatorial values. References to them do. In fact, different
references to the same variable can represent both a combinatorial and
a registered value. That's one of their attributes which makes them so
powerful. But that's another topic...
Andy