Help: what does this VHDL code mean?

P

Pratip Mukherjee

process(clock) is
begin
if clock'event and clock = '1'
then
o <= '1';
if (<some conditional>)
then
o <= '0';
end if;
end if;
end process;

My question is how to interpret this: is the value of o is first set to
'1' and then set to '0' or is it that o is set to '0' or '1' depending on
whether the condition is true. Is it a good VHDL coding style? If so, why
don't I see a single example/explanation of it in Peter Ashendon's book?
Thanks in advance.

- Pratip.
 
N

newsgroup

Hi Pratip,

The code will infer a mux and a flip flop.
For all cases in which <condition> is true output will be zero else one.

There is nothing wrong in this coding style, except for readability and
straightforwardness. It is equivalent to this code.
process(clock) is
begin
if clock'event and clock = '1' then
if (<some conditional>) then
o <= '0';
else
o <= '1' ;
end if;
end if;
end process;
 
K

Klaus Falser

process(clock) is
begin
if clock'event and clock = '1'
then
o <= '1';
if (<some conditional>)
then
o <= '0';
end if;
end if;
end process;

My question is how to interpret this: is the value of o is first set to
'1' and then set to '0' or is it that o is set to '0' or '1' depending on
whether the condition is true. Is it a good VHDL coding style? If so, why
don't I see a single example/explanation of it in Peter Ashendon's book?
Thanks in advance.

- Pratip.

This coding style is less useful together with an if statement,
but very useful in conjunction with a case statement
(when programming FSM's).

It allows you to assign a default value and set your output
signal only under certain conditions.

In the following example you have a output_enable signal
which must always be '0', exept when writing.

process(clock) is
begin
if rising_edge(clock) then
output_enable <= '0';
case (state) is
when idle =>
<do nothing, output_enable remains at '0'>
when writing =>
output_enable <= '1';
when reading =>
<something else, output_enable remains at '0'>
when someOtherState =>
<something else too, output_enable remains at '0'>
end case;
end if;
end process;

Without this style you had to assign a value for "output_enable"
in all states, blowing up your code.

The signal output_enable itself is NOT set first to '0' and
then to '1' when then when writing, but is set cleanly to '0'
or '1'.

Remember, in VHDL the new values for the signals are assigned
only at the end of the simulation cycle.
During the calculation of the new value for the signal there is an
intermediate result of '0', evenually replaced by '1' when we are
in the writing state, but the signal itself gets only the RESULT of
the calculus.

Best regards
Klaus Falser
 
F

fred

Maybe he doesn't think it is a good way to code, I would agree with him.
This coding style is less useful together with an if statement,
but very useful in conjunction with a case statement
(when programming FSM's).
IMO, dirty programming
It allows you to assign a default value and set your output
signal only under certain conditions.

In the following example you have a output_enable signal
which must always be '0', exept when writing.

process(clock) is
begin
if rising_edge(clock) then
output_enable <= '0';
case (state) is
when idle =>
<do nothing, output_enable remains at '0'>
when writing =>
output_enable <= '1';
when reading =>
<something else, output_enable remains at '0'>
when someOtherState =>
<something else too, output_enable remains at '0'>
end case;
end if;
end process;

Without this style you had to assign a value for "output_enable"
in all states, blowing up your code.
Any reason for not covering this with:
when (others) =>
output_enable <= '0';
which I think is a far cleaner.
Remember, in VHDL the new values for the signals are assigned
only at the end of the simulation cycle.
During the calculation of the new value for the signal there is an
intermediate result of '0', evenually replaced by '1' when we are
in the writing state, but the signal itself gets only the RESULT of
the calculus.
But life (hardware) isn't a simulation, I'd rather write something that follows
the way hardware will actually perform (albeit at a high level) than make
use techniques like those above.
 
K

Kim Enkovaara

fred said:
Any reason for not covering this with:
when (others) =>
output_enable <= '0';
which I think is a far cleaner.

That is different code at functional level, it should create latches.
In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
So in your code the output_enable value comes from the previous round in
the undefined cases.

Setting the default value at the beginning and changing it inside
the case clauses makes the code easier to read in very complex state
machines. It's easier to see, what values are important. Also in very
deep if-clauses that style usually cuts down the needed else branches.

But life (hardware) isn't a simulation, I'd rather write something that follows
the way hardware will actually perform (albeit at a high level) than make
use techniques like those above.

Simulation follows hardware, if synthesis subset of the language is used.
Setting default value is normal way of doing this for synthesizable code.

--Kim
 
F

fred

Kim said:
That is different code at functional level, it should create latches.
I disagree, a case is a decoder, the others term (the brackets were a
mistake btw) just fills in the empty slots, I see no latches.
In VHDL the case statements are mutually exclusive (1076-1993 8.8 Note 1).
So in your code the output_enable value comes from the previous round in
the undefined cases. Nope

Setting the default value at the beginning and changing it inside
the case clauses makes the code easier to read in very complex state
machines. It's easier to see, what values are important. Also in very
deep if-clauses that style usually cuts down the needed else branches.
From a real world hardware perspective I look upon this sort of thing as
multiple sources (even though in VHDL it is not) and so won't do it;
irrespective of whether tools 'know what I mean'.
Simulation follows hardware, if synthesis subset of the language is used.
Setting default value is normal way of doing this for synthesizable code.
In hardware, the signal does not set to one level and then change to
another one (or how ever many) deltas later so in that way simulation does
not follow hardware.
 
K

Klaus Falser

But life (hardware) isn't a simulation, I'd rather write something that
follows the way hardware will actually perform (albeit at a high level)
than make use techniques like those above.

This has nothing to do with simulation vs. hardware but is the way VHDL
works.
VHDL is simply NOT a programming language, an assignment to a signal in
VHDL is something completely different from an assigning of a value to a
variable (they exist in VHDL too !).
Be assured, if written this way the hardware will do exactly the same as
the code says.

Best regards
Klaus Falser
 
F

fred

Klaus Falser said:
This has nothing to do with simulation vs. hardware but is the way VHDL
works.
VHDL is simply NOT a programming language, an assignment to a signal in
VHDL is something completely different from an assigning of a value to a
variable (they exist in VHDL too !).
Yes, I know :)
Be assured, if written this way the hardware will do exactly the same as
the code says.
I didn't say it wouldn't, I said that I thought it was dirty programming and
that I don't write my code that way, you do not have to agree with that.
 
B

Ben Jones

VHDL is simply NOT a programming language

I respectfully disagree. Rather:

VHDL is not SIMPLY a programming language.

-Ben-
 
K

Klaus Falser

I disagree, a case is a decoder, the others term (the brackets were a
mistake btw) just fills in the empty slots, I see no latches.

From a real world hardware perspective I look upon this sort of thing as
multiple sources (even though in VHDL it is not) and so won't do it;
irrespective of whether tools 'know what I mean'.

In hardware, the signal does not set to one level and then change to
another one (or how ever many) deltas later so in that way simulation does
not follow hardware.

Hello Fred,
apart from the rest which is wrong too, you really have to take a book
and read how the VHDL simulator works.
The delta cycles you mention in your answer are something completely
different.
When writing a VHDL code like the following

process (clk) is
begin
o <= '0';
if (condition) then
o <= '1';
end if;
end process;

it does not mean that o gets a value of '0' and some time later it gets
a value of '1'.
The statements between the "begin" and the "end process" are SEQUENTIAL
STATEMENTS, which are executed at the same delta cycle and their purpose
is to calculate eventual new values for the driven signals (o in this
example).
When the elaboration reaches the "end process" statement the simulator
has found a new value for o, but only after ALL processes are elaborated
this way the new values are really dumped to the signals (if the new
value is different to the old one) and the signals effectively changed.
There is not spike in the simulated signal !

As I wrote it the other posting (I wrote it before I read this your
posting), VHDL is not a programming language !
 
F

fred

Klaus Falser said:
Hello Fred,
apart from the rest which is wrong too, you really have to take a book
and read how the VHDL simulator works.
Believe it or not, I do know, I'm just crap at describing the reasons why I
think this is a bad style.
As I wrote it the other posting (I wrote it before I read this your
posting), VHDL is not a programming language !
I think that was the point I was trying to make (badly).

Simply put I do not like this coding style so lets just leave it at that shall
we?
 
J

jtw

fred said:
Yes, I know :)

I didn't say it wouldn't, I said that I thought it was dirty programming
and
that I don't write my code that way, you do not have to agree with that.
Once upon a time, I didn't write code that way. I didn't even realize that
this was a valid way of writing code. Then, I had to take over someone
else's code, and that person had written quite a bit this way. After my
initial confusion, I realized that this is a simple (and perhaps elegant)
way of managing the defaults. The value of writing this varies from case to
case (not trying to be punny.)

I often try to write code this way, rather than handling that last 'else'.
But it's real value is, as someone mentioned, in complex state machines.
Someone mentioned creating latches; for this process clocked on an edge, it
won't create latches. And making an explicit 'others' description
superfluous is a small benefit. But for trying to quickly identify which
state and which conditions cause a change on a signal... priceless. (Just
kidding. But there are definitely times where this, more succint style, can
add to the readability.)

Jason
 
K

Kim Enkovaara

fred said:
I disagree, a case is a decoder, the others term (the brackets were a
mistake btw) just fills in the empty slots, I see no latches.



Nope

I think this is misunderstanding. I tought that you were trying to code the
code like this:

process(clock) is
begin
if rising_edge(clock) then
case (state) is
when idle => ...
when writing =>
output_enable <= '1';
when reading => ...
when someOtherState => ...
when others =>
output_enable <= '0';
end case;
end if;
end process;

And you tought:

process(clock) is
begin
if rising_edge(clock) then
case (state) is
when writing =>
output_enable <= '1';
when others =>
output_enable <= '0';
end case;
end if;
end process;

The example is little too simple, because usually there is a huge pile of
signals inside the states. And then the others option is quite difficult
to use. But the default value option is easy to use.

From a real world hardware perspective I look upon this sort of thing as
multiple sources (even though in VHDL it is not) and so won't do it;
irrespective of whether tools 'know what I mean'.

Usually there are multiple sources to the combinatorial network. And the
style does not imply multiple drivers to same signal. The tools
know what you mean, because they must do that by definition (check how signal
assignment and delta cycle is defined).

And that default value style is used by designers very frequently. Usually
by the more experienced designers. I sit on top of hunders of thousands
of lines of VHDL code, made by a legion of VHDL coders. It's fun to check
sometimes how different styles coders have, but also there are some
commonalities. There are some styles that are dangerous in terms
of the whole tool flow, but this is not one of them.

In hardware, the signal does not set to one level and then change to
another one (or how ever many) deltas later so in that way simulation does
not follow hardware.

In real HW the signal value can jump around during it's propagation
trough the combinatorial logic, so it is not stable. It just has to
be stable around the clock edge to fullfill the setup and hold times.
That makes debugging of huge netlist quite painful, especially if the valid
window is small due to tight timing.


--Kim
 
F

fred

jtw said:
Once upon a time, I didn't write code that way. I didn't even realize that
this was a valid way of writing code. Then, I had to take over someone
else's code, and that person had written quite a bit this way. After my
initial confusion, I realized that this is a simple (and perhaps elegant)
way of managing the defaults. The value of writing this varies from case to
case (not trying to be punny.)

I often try to write code this way, rather than handling that last 'else'.
But it's real value is, as someone mentioned, in complex state machines.
Someone mentioned creating latches; for this process clocked on an edge, it
won't create latches. And making an explicit 'others' description
superfluous is a small benefit. But for trying to quickly identify which
state and which conditions cause a change on a signal... priceless. (Just
kidding. But there are definitely times where this, more succint style, can
add to the readability.)

Jason
I've yet to see the light but will try to keep an open mind :)
 
M

Mike Treseler

Kim said:
In real HW the signal value can jump around during it's propagation
trough the combinatorial logic, so it is not stable. It just has to
be stable around the clock edge to fullfill the setup and hold times.
That makes debugging of huge netlist quite painful, especially if the valid
window is small due to tight timing.

True, but static timing can find the paths.

-- Mike Treseler
 
K

Kim Enkovaara

Mike said:
True, but static timing can find the paths.

Unless there are bugs in the simulation or STA models. That happens
from time to time. And those are not fun to debug. In my opinion
netlevel simulations are only useful to find STA setup errors and
possible problems between two views of the timing model.

--Kim
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top