Null statement in VHDL

They sometimes make a nice placeholder for a comment:

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

Yes. What's the question?

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

Get the latest available, but I would get a copy of Ashenden, a good vhdl simulator, and master those first.

-- Mike Treseler

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

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

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

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

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.

Yeah, both of those bug me. It's so difficult to achieve truly universal constants in a design.

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.

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

..snip

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

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

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

|------------------------------------------------------------------------| |"[..] | | | |> 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

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 news: snipped-for-privacy@o80g2000hse.googlegroups.com timestamped Tue, 28 Aug 2007 07:45:18 -0000, "comp.arch.fpga" 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

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 would say that they do not question decisions that were made by synopsys 20 years ago.

Hmm. I just have to counter that post here.

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

At extra hardware cost on my platform.

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.

Surely the OP meant "ASIC designres".

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

Andy and Mike, >> From 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.

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.

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.

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

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

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