Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Null statement in VHDL

Reply
Thread Tools

Null statement in VHDL

 
 
KJ
Guest
Posts: n/a
 
      09-02-2007

"Jonathan Bromley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Tue, 28 Aug 2007 14:26:59 -0000, "comp.arch.fpga"
> <(E-Mail Removed)> 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


 
Reply With Quote
 
 
 
 
Jonathan Bromley
Guest
Posts: n/a
 
      09-03-2007
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
http://www.velocityreviews.com/forums/(E-Mail 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.
 
Reply With Quote
 
 
 
 
KJ
Guest
Posts: n/a
 
      09-03-2007

"Jonathan Bromley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
comp.arch.fpga
Guest
Posts: n/a
 
      09-04-2007
On 3 Sep., 09:53, Jonathan Bromley <(E-Mail Removed)>
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



 
Reply With Quote
 
Jonathan Bromley
Guest
Posts: n/a
 
      09-04-2007
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
(E-Mail 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.
 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      09-05-2007
On Sep 3, 9:28 am, "KJ" <(E-Mail Removed)> wrote:
> "Jonathan Bromley" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>
> > 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


 
Reply With Quote
 
Andy
Guest
Posts: n/a
 
      09-05-2007

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
"stringObj == null" vs "stringObj.equals(null)", for null check?? qazmlp1209@rediffmail.com Java 5 03-29-2006 10:37 PM
Re: When do I always put a "else NULL" statement in my VHDL code? walala VHDL 2 10-11-2003 10:51 PM
About Latches and Registers was (When do I always put a "else NULL"statement in my VHDL code?) Ingmar Seifert VHDL 0 09-14-2003 07:57 PM
Re: When do I always put a "else NULL" statement in my VHDL code? Kelvin VHDL 1 09-13-2003 11:07 AM
Re: When do I always put a "else NULL" statement in my VHDL code? Mike Treseler VHDL 0 09-12-2003 09:41 PM



Advertisments