Null statement in VHDL

I don't recall the thread but I totally agree with you.

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.

And publicize against the tools that don't support the language.

KJ

Reply to
KJ
Loading thread data ...

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
 Click to see the full signature
Reply to
Jonathan Bromley

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.

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

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.

  1. 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 to
comp.arch.fpga

Agreed with both your points, although my experience is consistently that those bad things do *not* happen in practice.

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
 Click to see the full signature
Reply to
Jonathan Bromley

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

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

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.