Null statement in VHDL

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:shbmd3pmpmo6sfkqj46lv0ls2dhssq2di0@4ax.com...

On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga"
ksulimma@googlemail.com> wrote:


E.g. Jonathan Bromley posted on 2007 March 5th:
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,

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]

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

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:71fnd39ctb6egc7jjloldmvn9pjnr96u4s@4ax.com...

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]

On 3 Sep., 09:53, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
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 Tue, 04 Sep 2007 07:16:36 -0000, "comp.arch.fpga" wrote:

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

 

[Andy]

On Sep 3, 9:28 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

"Jonathan Bromley" <jonathan.brom...@MYCOMPANY.com> wrote in message

news:71fnd39ctb6egc7jjloldmvn9pjnr96u4s@4ax.com...

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

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