Ask a question - edaboard.com
elektroda.net NewsGroups Forum Index - VHDL Language - one signal set ffrom two processes .....
Alessandro Basili
Guest
Guest
Sat Jul 09, 2011 5:23 am
On 7/8/2011 6:08 PM, KJ wrote:
Quote:
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).
(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".
Quote:
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.
'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:
Quote:
http://klabs.org/richcontent/software_content/safe_state_machines_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???]).
Quote:
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.
- 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
Martin Thompson
Guest
Guest
Mon Jul 11, 2011 10:07 am
Paul Uiterlinden <puiterl_at_notaimvalley.nl> writes:
Quote:
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.
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
--
martin.j.thompson_at_trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware
Alessandro Basili
Guest
Guest
Mon Jul 11, 2011 3:07 pm
On 7/11/2011 12:07 PM, Martin Thompson wrote:
[...]
Quote:
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;
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 (*)?
Quote:
very interesting approach. And I do share the same view when you say:
Quote:
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.
Quote:
(apologies to Chrome users, the code wraps rather than providing scroll-bars
like in Firefox. I haven't figured out why yet)
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/issues/detail?id=10533
even though they claim they fixed this problem...
(*) my apologies I cannot try it out myself...reinstalling my pc!
Martin Thompson
Guest
Guest
Tue Jul 12, 2011 8:46 am
Alessandro Basili <alessandro.basili_at_cern.ch> writes:
Quote:
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
[...]
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)
^^^^^^^^^^^^^^^^^^^^^^
Quote:
- if reset = '1' exit the main loop.
Am I wrong (*)?
Am I wrong (*)?
reset is also "in the sensitivity list" of the wait statement.
Quote:
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.
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 :)
Quote:
- 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.
Quote:
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.
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)
Alessandro Basili
Guest
Guest
Tue Jul 12, 2011 1:20 pm
On 7/12/2011 10:46 AM, Martin Thompson wrote:
Quote:
Alessandro Basili <alessandro.basili_at_cern.ch> 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)
^^^^^^^^^^^^^^^^^^^^^^
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.
elektroda.net NewsGroups Forum Index - VHDL Language - one signal set ffrom two processes .....
