Help: what does this VHDL code mean?

P

Pratip Mukherjee

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



"Pratip Mukherjee" <pratipm@hotmail.com> wrote in message
news:062dner0G_B2ViXfRVn-iA@comcast.com...
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.
Click to expand...
 
In article <062dner0G_B2ViXfRVn-iA@comcast.com>, pratipm@hotmail.com
says...
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.
Click to expand...
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
 
In article <MPG.1d2330ea922ab57298968c@news.inet.it>, Klaus Falser
<kfalser@durst.it> writes
In article <062dner0G_B2ViXfRVn-iA@comcast.com>, pratipm@hotmail.com
says...
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?
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
Click to expand...

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:
Click to expand...
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
Click to expand...
the way hardware will actually perform (albeit at a high level) than make
use techniques like those above.
--
fred
 
fred wrote:

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.
Click to expand...
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.


Remember, in VHDL the new values for the signals are assigned
only at the end of the simulation cycle.

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.
Click to expand...
Simulation follows hardware, if synthesis subset of the language is used.
Setting default value is normal way of doing this for synthesizable code.

--Kim
 
In article <whcue.8035$7%2.3266@reader1.news.jippii.net>, Kim
Enkovaara <kim.enkovaara@iki.fi> writes
fred wrote:

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.

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
Click to expand...
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
Click to expand...

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
Click to expand...
multiple sources (even though in VHDL it is not) and so won't do it;
irrespective of whether tools 'know what I mean'.

Remember, in VHDL the new values for the signals are assigned
only at the end of the simulation cycle.

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.
In hardware, the signal does not set to one level and then change to
Click to expand...
another one (or how ever many) deltas later so in that way simulation does
not follow hardware.
--
fred
 
In article <paVK6BAOcSuCFwmV@y.z>, not@for.mail says...
In article <MPG.1d2330ea922ab57298968c@news.inet.it>, Klaus Falser
kfalser@durst.it> writes
...
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.
Click to expand...
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
 
In article <MPG.1d239445cd2be58598968d@news.inet.it>, Klaus Falser
<kfalser@durst.it> writes
In article <paVK6BAOcSuCFwmV@y.z>, not@for.mail says...
In article <MPG.1d2330ea922ab57298968c@news.inet.it>, Klaus Falser
kfalser@durst.it> writes
...
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.


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 :)
Click to expand...

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
Click to expand...
that I don't write my code that way, you do not have to agree with that.

--
fred
 
In article <y$scjTAoDXuCFwW9@y.z>, not@for.mail says...
In article <whcue.8035$7%2.3266@reader1.news.jippii.net>, Kim
Enkovaara <kim.enkovaara@iki.fi> writes
fred wrote:

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.

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

Remember, in VHDL the new values for the signals are assigned
only at the end of the simulation cycle.

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.
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.
Click to expand...
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 !
 
In article <MPG.1d239beb43ebbc6098968e@news.inet.it>, Klaus Falser
<kfalser@durst.it> writes
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
Click to expand...
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).
Click to expand...

Simply put I do not like this coding style so lets just leave it at that shall
we?
--
fred
 
"fred" <not@for.mail> wrote in message news:V$VVzZAMmXuCFwzT@y.z...
In article <MPG.1d239445cd2be58598968d@news.inet.it>, Klaus Falser
kfalser@durst.it> writes
In article <paVK6BAOcSuCFwmV@y.z>, not@for.mail says...
In article <MPG.1d2330ea922ab57298968c@news.inet.it>, Klaus Falser
kfalser@durst.it> writes
...
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.


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.

--
fred
Once upon a time, I didn't write code that way. I didn't even realize that
Click to expand...
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
 
fred wrote:

In article <whcue.8035$7%2.3266@reader1.news.jippii.net>, Kim
Enkovaara <kim.enkovaara@iki.fi> writes

fred wrote:


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.

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
Click to expand...
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'.
Click to expand...
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.


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.
Click to expand...
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
 
In article <OVoue.1320$N22.1138@newssvr21.news.prodigy.com>, jtw
<wrightjt@hotmail.invalid> writes
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 :)
Click to expand...
--
fred
 
Kim Enkovaara wrote:

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.
Click to expand...
True, but static timing can find the paths.

-- Mike Treseler
 
Mike Treseler wrote:
Kim Enkovaara wrote:

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.
Click to expand...
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
 
More probably it will infer an NOT of condition to the 'd' input of
the FF.
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top