«

Alessandro Basili wrote:

>> "WAIT until rising_edge(clk);" is a perfectly legitimate way of
>> specifying the clock of a clocked process and is simpler to code than
>> the "if then end if" syntax.
>
> I'm not blaming the illegitimacy of the statement, I simply dislike it
> as to me it lacks of readability

For me readability is the main reason for using and promoting to use "WAIT
UNTIL clk='1'" (or "WAIT UNTIL rising_edge(clk)").

As soon as I see "WAIT UNTIL clk='1'", I know that I need not look further
to see what kind of process it is. It is a pure clocked process without any
asynchronicities.

Another (visual/layout) advantage is the lack of a long stretched if-end-if
statement, which eats up indentation as well.

> and as well the possibility to include
> an asynch reset to the process. If you can post a snippet of a code
> including an asynch reset I would appreciate.

That is not possible with the WAIT statement.

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

"Paul Uiterlinden" <> wrote in message
news:4e16f3ef$0$21846$ l...
> For me readability is the main reason for using and promoting to use
> "WAIT
> UNTIL clk='1'" (or "WAIT UNTIL rising_edge(clk)").
>
> As soon as I see "WAIT UNTIL clk='1'", I know that I need not look
> further
> to see what kind of process it is. It is a pure clocked process
> without any
> asynchronicities.
>
> Another (visual/layout) advantage is the lack of a long stretched
> if-end-if
> statement, which eats up indentation as well.
>
My sentiments exactly.

Also, regarding asynchronous resets, those should be avoided wherever
possible. The logic team I work with is just finishing an ASIC with
over 900,000 latches. Only a very small handful of those have
asynchronous resets. That was for a case where some logic needed to be
reset when the clock wasn't running.

Charles Bailey

On Jul 8, 1:02*am, Alessandro Basili <alessandro.bas...@cern.ch>
wrote:
> On 7/8/2011 6:04 AM, logic_guy wrote:
> >> The clause "when others =>" should also be added, to land always on a
> >> "safe" state.
> > An "others" clause is not needed here since "state" is defined with
> > exactly 5 states, so there are no other states. *If you did put an
> > "others" clause there some tools would give you a warning that the
> > "others" clause is unreachable.
>
> Depending on the encoding (onehot, gray, etc.) the number of FF you are
> going to use certainly gives you more than 5 states (32 for onehot, 8
> for gray). How the synthesizer is going to know what to do in case your
> FF are presenting a state that is not among the 5?
> But maybe you care if a bit flip will put your FSM in a state out of
> which it cannot get out.
>

The synthesis tool default is not to implement safe state machines
(i.e. ones that return to a particular state if it ever gets into an
'illegal' state).

Unless you play with that synthesis tool setting you will not get
'safe state machines'. In particular, you will not get 'safe state
machines' regardless of how the FSM states are encoded. But don't
take my word for it, try your own state machine with and without an
otherwise unreachable 'when others' clause, and you should see that
you get the same implementation regardless of state bit encoding...or
likely regardless of any other settings other than the tool control
specifically for implementing safe state machines.

As a parting note, the causes for getting into an illegal state are:
- Timing problem
- SEU

In neither of these situations would it be likely that the correct
course of action would be to simply go to some arbitrary reset state.

Kevin Jennings

On 7/8/2011 6:08 PM, KJ wrote:
> The synthesis tool default is not to implement safe state machines
> (i.e. ones that return to a particular state if it ever gets into an
> 'illegal' state).
>

Indeed I used to turn on the "safe" mode in Synplify to have what I
"wanted".

> Unless you play with that synthesis tool setting you will not get
> 'safe state machines'. In particular, you will not get 'safe state
> machines' regardless of how the FSM states are encoded. But don't
> take my word for it, try your own state machine with and without an
> otherwise unreachable 'when others' clause, and you should see that
> you get the same implementation regardless of state bit encoding...or
> likely regardless of any other settings other than the tool control
> specifically for implementing safe state machines.
>

And indeed the tool tends to optimize away all the "unnecessary" FF
regardless of the encoding. What I did not know is that in the "safe"
mode the 'when others' clause is not really followed the way it is
written and Synplify will resolve the illegal state to the reset state,
whether it is asynchronous or synchronous:

> http://klabs.org/richcontent/softwar...synplify_1.pdf

To force the tool to follow the 'when others' clause it is suggested to
turn off the the FSM compiler. At this point the 'when others' clause
will be exactly followed (provided the "enumerated type" is changed with
constants [why???]).

> As a parting note, the causes for getting into an illegal state are:
> - Timing problem
> - SEU
>
> In neither of these situations would it be likely that the correct
> course of action would be to simply go to some arbitrary reset state.
>

Assuming the design has gone through timing analysis, the SEU is really
a concern that in some applications may get you in troubles. That is why
some communication protocols for space applications (ex. spacewire) can
recover if the FSM fail over the reset state, causing the link on both
sides to an "exchange of silence" procedure that will restore communication.

I do agree that some time a "safe" state maybe safe from the FSM point
of view but system wise doesn't help that much, unless every part of the
design is designed to tolerate it.

Al

Paul Uiterlinden <> writes:

> Alessandro Basili wrote:
>> and as well the possibility to include
>> an asynch reset to the process. If you can post a snippet of a code
>> including an asynch reset I would appreciate.
>
> That is not possible with the WAIT statement.

It sort of is... but it's unpleasant in various ways:

process is
begin
-- do_reset things here
wait until reset = '0'; -- wait until reset goes away
main : loop
wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
-- do one set of things
wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
-- do another set of things
-- etc.. repeat long wait until line as many times as necessary
end loop;
end process;

Also on "inferred state machines":

http://parallelpoints.com/node/69

(apologies to Chrome users, the code wraps rather than providing scroll-bars
like in Firefox. I haven't figured out why yet)

Cheers,
Martin

--

TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities...ronic-hardware

On 7/11/2011 12:07 PM, Martin Thompson wrote:
[...]
> process is
> begin
> -- do_reset things here
> wait until reset = '0'; -- wait until reset goes away
> main : loop
> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
> -- do one set of things
> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
> -- do another set of things
> -- etc.. repeat long wait until line as many times as necessary
> end loop;
> end process;
>

Isn't the "exit main when reset = '1'" a synchronous reset? The way I
read is the following:

- wait until rising_edge(clk) and then
- if reset = '1' exit the main loop.

Am I wrong (*)?

> Also on "inferred state machines":
>
> http://parallelpoints.com/node/69
>

very interesting approach. And I do share the same view when you say:

> it saves you having to think of names for your states

since IMHO what is more critical is the condition under which an FSM
moves from one state to the other, rather than the state itself.
The suggestion to move at a higher level of description and leave the
synthesizer infer whatever is needed to perform the functionality
described is the right way of exploiting the language. Too many times we
loose ourselves amongst gates and flops forgetting the big picture.

Two comments though:

- giving the impression that "less code is usually good" is a
misconception (as Nemo's father would say about clownfish). Being on the
defense line "the smaller the better" usually drives designers to write
unreadable and therefore unmaintainable code.

- comparing vhdl with C# in terms of lines of code is risky. Hardware
acceleration is nothing related to the lines of code and its main goal
is to search for tasks in the sequential (and/or multi-threaded)
computing that can be performed in parallel by an external device (or
additional dedicated CPU) in the hope of being more efficient (number of
computations/cycle). Nothing related to lines of code.

> (apologies to Chrome users, the code wraps rather than providing scroll-bars
> like in Firefox. I haven't figured out why yet)
>

Didn't work for me as well, but found the following:

http://code.google.com/p/chromium/is...etail?id=10533

even though they claim they fixed this problem...

(*) my apologies I cannot try it out myself...reinstalling my pc!

Alessandro Basili <> writes:

> On 7/11/2011 12:07 PM, Martin Thompson wrote:
> [...]
>> process is
>> begin
>> -- do_reset things here
>> wait until reset = '0'; -- wait until reset goes away
>> main : loop
>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
>> -- do one set of things
>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
>> -- do another set of things
>> -- etc.. repeat long wait until line as many times as necessary
>> end loop;
>> end process;
>>
>
> Isn't the "exit main when reset = '1'" a synchronous reset? The way I
> read is the following:
>
> - wait until rising_edge(clk) and then

wait until rising_edge(clk) or falling_edge(reset)
^^^^^^^^^^^^^^^^^^^^^^

> - if reset = '1' exit the main loop.
>
> Am I wrong (*)?
>

reset is also "in the sensitivity list" of the wait statement.

>> Also on "inferred state machines":
>>
>> http://parallelpoints.com/node/69
>>
>
> very interesting approach. And I do share the same view when you say:
>
>> it saves you having to think of names for your states
>
> since IMHO what is more critical is the condition under which an FSM
> moves from one state to the other, rather than the state itself.
> The suggestion to move at a higher level of description and leave the
> synthesizer infer whatever is needed to perform the functionality
> described is the right way of exploiting the language. Too many times we
> loose ourselves amongst gates and flops forgetting the big picture.
>
> Two comments though:
>
> - giving the impression that "less code is usually good" is a
> misconception (as Nemo's father would say about clownfish). Being on the
> defense line "the smaller the better" usually drives designers to write
> unreadable and therefore unmaintainable code.
>

Yes, it always needs some common-sense applying. But note that I didn't
say "smaller is better".

"Less code is *usually* good". A much weaker assertion

> - comparing vhdl with C# in terms of lines of code is risky.

Oh, yes of course - it's not meant to be much more than a
pseudo-academic "playing with possibilities". My original motivation
was simply in response to the originally presented HDL solution to show
that the VHDL *could* look much like the C# approach. (Bar the
horrible-ness of the clocking construct).

But I also feel that "lines of code" is not a metric to be completely
discarded.

> Hardware acceleration is nothing related to the lines of code and its
> main goal is to search for tasks in the sequential (and/or
> multi-threaded) computing that can be performed in parallel by an
> external device (or additional dedicated CPU) in the hope of being
> more efficient (number of computations/cycle). Nothing related to
> lines of code.

No, but if you can (readably!) do the same thing in many less lines of
code, that's a win, surely? LOC matters not to the machine, but it is
still a significant metric to the programmer/designer, and even more so
to the reviewers of said code.

Cheers,
Martin
(all his own opinions)

On 7/12/2011 10:46 AM, Martin Thompson wrote:
> Alessandro Basili <> writes:
>
>> On 7/11/2011 12:07 PM, Martin Thompson wrote:
>> [...]
>>> process is
>>> begin
>>> -- do_reset things here
>>> wait until reset = '0'; -- wait until reset goes away
>>> main : loop
>>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
>>> -- do one set of things
>>> wait until rising_edge(clk) or falling_edge(reset); exit main when reset = '1';
>>> -- do another set of things
>>> -- etc.. repeat long wait until line as many times as necessary
>>> end loop;
>>> end process;
>>>
>>
>> Isn't the "exit main when reset = '1'" a synchronous reset? The way I
>> read is the following:
>>
>> - wait until rising_edge(clk) and then
>
> wait until rising_edge(clk) or falling_edge(reset)
> ^^^^^^^^^^^^^^^^^^^^^^
>

I was much too distracted by the "exit main when reset = '1';" that I
totally miss that! Uhm, talking about readability I do admit the reader
sometimes has his/her own responsability
My apologies.