Help: what does this VHDL code mean?

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.

Pratip Mukherjee

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" <> wrote in message
news:062dner0G_B2ViXfRVn-...
> 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.

newsgroup

More probably it will infer an NOT of condition to the 'd' input of
the FF.

Neo

In article <062dner0G_B2ViXfRVn->,
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.
>

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

Klaus Falser

In article <>, Klaus Falser
<> writes
>In article <062dner0G_B2ViXfRVn->,
>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

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

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.

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.

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

--Kim

Kim Enkovaara

In article <whcue.8035$7%>, Kim
Enkovaara <> 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.
--
fred

fred

In article <>, says...
> In article <>, Klaus Falser
> <> 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 !).
Be assured, if written this way the hardware will do exactly the same as
the code says.

Best regards
Klaus Falser

Klaus Falser

In article <>, Klaus Falser
<> writes
>In article <>, says...
>> In article <>, Klaus Falser
>> <> 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

fred

> VHDL is simply NOT a programming language

I respectfully disagree. Rather:

VHDL is not SIMPLY a programming language.

-Ben-

Ben Jones