 |
|
| Computers Forum Index » Computer Architecture - FPGA » Simple state machine output question... |
|
Page 1 of 1 |
|
| Author |
Message |
| TSMGrizzly... |
 Posted: Fri Oct 30, 2009 6:23 am |
|
|
|
Guest
|
In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.
Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched? Is this sound
coding practice?
Thanks,
TSM |
|
|
| Back to top |
|
|
|
| backhus... |
| Posted: Fri Oct 30, 2009 6:37 am |
|
|
|
Guest
|
On 30 Okt., 07:23, TSMGrizzly <sbatt... at (no spam) yahoo.co.jp> wrote:
Quote: In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.
Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched? Is this sound
coding practice?
Thanks,
TSM
Hi,
don't say "latched" here, with FPGAs we all want signals to be
registered. ;-)
And so, if your outputs are set in a registered process you can set
them once and they keep that value as long as they are unchanged.
But it's quite difficult do achieve with a standard two process FSM,
where branches and outputs are handled in a combinatorical process.
Ugly.
In the past I favoured three process FSMs, but now I'm doing it in one
process, where the state is stored in a variable (and the state type
defined inside the process).
Have a nice synthesis
Eilert |
|
|
| Back to top |
|
|
|
| KJ... |
| Posted: Fri Oct 30, 2009 11:16 am |
|
|
|
Guest
|
On Oct 30, 2:23 am, TSMGrizzly <sbatt... at (no spam) yahoo.co.jp> wrote:
Quote: In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.
Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched?
No. Think for a minute about it. You've got some output that is
coming out of a flip flop. If you don't want it to change values then
you make the default assignment to assign that output to the value
currently in the output of the flop.
Quote: Is this sound coding practice?
The unsound practice is using an unclocked process which then implies
that it is unsound to use a two process model. Processes with a
sensitivity list that consist of more than just 'clock' are prone to
creating design problems that are just not possible when written as a
single clocked process [1].
Despite what textbooks would have you believe, state machines do not
need to be coded as two processes.
KJ
[1] The problems with an unclocked process are:
- Must insure that there is an assignment to every signal on every
path through the process or a latch will be created which is a design
problem that will need to then be fixed...after having to debug to
find the problem. Typically this is accomplished by assigning default
values at the begining of the process
- Must insure that the sensitivity list is complete or the synthesized
result will not match the code as written and interpreted by the
simulator.
- The default assignments are extra code that is not needed if written
as a single process instead....it's your time. |
|
|
| Back to top |
|
|
|
| Gabor... |
| Posted: Fri Oct 30, 2009 1:25 pm |
|
|
|
Guest
|
On Oct 30, 7:16 am, KJ <kkjenni... at (no spam) sbcglobal.net> wrote:
Quote: On Oct 30, 2:23 am, TSMGrizzly <sbatt... at (no spam) yahoo.co.jp> wrote:
In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.
Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched?
No. Think for a minute about it. You've got some output that is
coming out of a flip flop. If you don't want it to change values then
you make the default assignment to assign that output to the value
currently in the output of the flop.
Is this sound coding practice?
The unsound practice is using an unclocked process which then implies
that it is unsound to use a two process model. Processes with a
sensitivity list that consist of more than just 'clock' are prone to
creating design problems that are just not possible when written as a
single clocked process [1].
Despite what textbooks would have you believe, state machines do not
need to be coded as two processes.
KJ
[1] The problems with an unclocked process are:
- Must insure that there is an assignment to every signal on every
path through the process or a latch will be created which is a design
problem that will need to then be fixed...after having to debug to
find the problem. Typically this is accomplished by assigning default
values at the begining of the process
- Must insure that the sensitivity list is complete or the synthesized
result will not match the code as written and interpreted by the
simulator.
- The default assignments are extra code that is not needed if written
as a single process instead....it's your time.
Well, in the unclocked process you could make default assigns
that are not to a constant but rather to the current output
of the flip-flop in the clocked process. Then drop into the
case statement. This is similar to what you get for "free"
in the single-clocked-process FSM. What you lose in the
clocked-only FSM is the ability to assign outputs based on
the current state in the same process. I don't think there's
anything inherently wrong with the two process approach as
long as you understand what you're making. In the one-clock
FSM process you'd often end up with outputs assigned in
another process that depend on the state variable in order
to accomplish the same end. I don't see how that's in any
way better than the two-process FSM.
Just my 2 cents,
Gabor |
|
|
| Back to top |
|
|
|
| KJ... |
| Posted: Fri Oct 30, 2009 3:06 pm |
|
|
|
Guest
|
On Oct 30, 9:25 am, Gabor <ga... at (no spam) alacron.com> wrote:
Quote: On Oct 30, 7:16 am, KJ <kkjenni... at (no spam) sbcglobal.net> wrote:
On Oct 30, 2:23 am, TSMGrizzly <sbatt... at (no spam) yahoo.co.jp> wrote:
In a two-process state machine with many outputs, I would like to have
a few output signals whose values would be updated and latched on
certain states, and left as they are during all other states.
Is it correct that this can be accomplished by simply not assigning
these signals with default values, and only including assignments for
them during the states where I would like them latched?
No. Think for a minute about it. You've got some output that is
coming out of a flip flop. If you don't want it to change values then
you make the default assignment to assign that output to the value
currently in the output of the flop.
Is this sound coding practice?
The unsound practice is using an unclocked process which then implies
that it is unsound to use a two process model. Processes with a
sensitivity list that consist of more than just 'clock' are prone to
creating design problems that are just not possible when written as a
single clocked process [1].
Despite what textbooks would have you believe, state machines do not
need to be coded as two processes.
KJ
[1] The problems with an unclocked process are:
- Must insure that there is an assignment to every signal on every
path through the process or a latch will be created which is a design
problem that will need to then be fixed...after having to debug to
find the problem. Typically this is accomplished by assigning default
values at the begining of the process
- Must insure that the sensitivity list is complete or the synthesized
result will not match the code as written and interpreted by the
simulator.
- The default assignments are extra code that is not needed if written
as a single process instead....it's your time.
Well, in the unclocked process you could make default assigns
that are not to a constant but rather to the current output
of the flip-flop in the clocked process.
That's what I said...so I guess we agree.
Quote: What you lose in the
clocked-only FSM is the ability to assign outputs based on
the current state in the same process.
Unclocked outputs that are a function of current state can be handled
with concurrent assignments. Treseler and Andy prefer to use
variables and keep it all within the same process.
Unclocked outputs that are a function of the next state are best
handled with variables within the process. Handling them with
concurrent assignments causes one to duplicate logic.
In any case, there is nothing lost by having only one clocked process
rather than two.
Quote: I don't think there's
anything inherently wrong with the two process approach as
long as you understand what you're making.
What is wrong with the two process approach is summed up in note [1]
in my previous post. Yes, you can work around it, but doing so
requires manual eyeball verification to insure the potholes have been
missed. Personally, I prefer a road with no potholes.
Quote: In the one-clock
FSM process you'd often end up with outputs assigned in
another process that depend on the state variable in order
to accomplish the same end.
One can use signals in/out of the clocked process to avoid references
to the state variable from outside the process if such references go
against your grain.
Again, the Treseler approach using variables avoids use of the state
variable from outside the process...however this is just a
technicality since his approach is to make the entire architecture one
large process. The references to the state variable could be
scattered all over that one large process, but technically there are
no references to the state variable from outside the process. The
distinctions only a nit-picker would love.
Quote: I don't see how that's in any
way better than the two-process FSM.
As I said in the first post, the two-process approach inherently has
an unclocked process. The problems with an unclocked process are
defined in note [1] in that same first post.
Kevin Jennings |
|
|
| Back to top |
|
|
|
| Andy... |
| Posted: Fri Oct 30, 2009 3:26 pm |
|
|
|
Guest
|
On Oct 30, 8:25 am, Gabor <ga... at (no spam) alacron.com> wrote:
Quote: What you lose in the
clocked-only FSM is the ability to assign outputs based on
the current state in the same process. I don't think there's
anything inherently wrong with the two process approach as
long as you understand what you're making. In the one-clock
FSM process you'd often end up with outputs assigned in
another process that depend on the state variable in order
to accomplish the same end. I don't see how that's in any
way better than the two-process FSM.
If at all possible, I rearrange states and/or output assignments
between them to avoid comibinatorial outputs, period.
If necessary, you CAN create combinatorial outputs from the state
registers in a single, clocked process, if you use a variable for the
state:
process (clk) is -- reset omitted for brevity
variable state : state_type;
begin
if rising_edge(clk) then
case state is
when ... =>
state := ... ;
end case;
end if;
-- combinatorial logic after state regs:
output <= some_function_of(state, other_variables);
end process;
One other reason not to use combinatorial processes: simulators
optimize process overhead by merging processes with the same
sensitivity list. And since most combinatorial processes will have
unique sensitivity lists, they cannot be merged.
The use of variables is more efficient to simulate, and keeping one
process minimizes use of signals. Variables also hide the state
definitions from outside the process, making future maintenance of
them easier (less impact on other parts of the design if they could
not use your state variable in the first place).
If your synthesis tool does not accept signal assignments after the
clocked if-then-end-if, call the vendor and tell them that (at least)
Synplify and Quartus do.
Andy |
|
|
| Back to top |
|
|
|
| Andy... |
| Posted: Fri Oct 30, 2009 6:38 pm |
|
|
|
Guest
|
On Oct 30, 11:09 am, Mike Treseler <mtrese... at (no spam) gmail.com> wrote:
Quote: And if I don't limit myself to one
variable per process, my code is
already in this merged format and
easier to trace in modelsim.
Simulators can merge processes with the same sensitivity list even
accross hierarchy.
If you wanted a little more privacy in a large single process, you
could use procedures with local variables to create islands of
locality within one process. You could still have "global" (within the
process) variables by declaring those before the procedures in the
process' declarative region.
To expand upon the timer/fsm example I posted a couple of weeks ago,
you could have a timer procedure and an fsm procedure within a
process, with local and "global" variables as desired. E.g. If the
timer/timeout variables were declared before both procedures, then
they could be read and manipulated by both, but if the state variable
was declared within the FSM process, only FSM could read/manipulate
the state.
I have seen some of your examples illustrate the use of procedures in
template processes, but I don't remember any specific to scope
control.
Andy |
|
|
| Back to top |
|
|
|
| Mike Treseler... |
| Posted: Fri Oct 30, 2009 7:04 pm |
|
|
|
Guest
|
Gabor wrote:
Quote: In the one-clock
FSM process you'd often end up with outputs assigned in
another process that depend on the state variable in order
to accomplish the same end. I don't see how that's in any
way better than the two-process FSM.
I would add any logic that depends on that
state variable to the same process.
Me too.
-- Mike Treseler |
|
|
| Back to top |
|
|
|
| Mike Treseler... |
| Posted: Fri Oct 30, 2009 8:09 pm |
|
|
|
Guest
|
Andy wrote:
Quote: If at all possible, I rearrange states and/or output assignments
between them to avoid combinatorial outputs, period.
I agree.
I like clean, synchronous interfaces between processes.
Quote: One other reason not to use combinatorial processes: simulators
optimize process overhead by merging processes with the same
sensitivity list. And since most combinatorial processes will have
unique sensitivity lists, they cannot be merged.
And if I don't limit myself to one
variable per process, my code is
already in this merged format and
easier to trace in modelsim.
-- Mike Treseler |
|
|
| Back to top |
|
|
|
| Mike Treseler... |
| Posted: Fri Oct 30, 2009 8:43 pm |
|
|
|
Guest
|
KJ wrote:
Quote: Unclocked outputs that are a function of the next state are best
handled with variables within the process. Handling them with
concurrent assignments causes one to duplicate logic.
A good point. In a clocked process,
a variable ID represents the D side of some register.
A port or signal ID represents the Q of some register.
-- Mike Treseler |
|
|
| Back to top |
|
|
|
| Mike Treseler... |
| Posted: Fri Oct 30, 2009 11:11 pm |
|
|
|
Guest
|
Andy wrote:
Quote: To expand upon the timer/fsm example I posted a couple of weeks ago,
you could have a timer procedure and an fsm procedure within a
process, with local and "global" variables as desired. E.g. If the
timer/timeout variables were declared before both procedures, then
they could be read and manipulated by both, but if the state variable
was declared within the FSM process, only FSM could read/manipulate
the state.
I hear what you're saying.
If I had to put unrelated registers in the same entity,
I would do it like that.
I prefer to keep related registers together
and port map the wired interfaces to keep
the signal directions explicit.
Quote: I have seen some of your examples illustrate the use of procedures in
template processes, but I don't remember any specific to scope
control.
I use port maps for scope control.
-- Mike Treseler |
|
|
| Back to top |
|
|
|
| TSMGrizzly... |
| Posted: Sat Oct 31, 2009 5:10 am |
|
|
|
Guest
|
Thanks for all the informative replies!
The book that I use as a VHDL reference does not go this deeply in the
subject of state machines, so I was a little lost.
I had a hunch that it was maybe not a good idea... as backhus'
response suggested, what I want are not latches, but registers to
store values from a few possible MUX'd input sources depending on the
state.. I should have been more clear on that.
And I think I may have been convinced to try the one clocked process
approach.. thankfully I was just finishing up the design of the states
and transitions, and haven't gotten too far into writing the code, so
I don't have to backtrack too much  |
|
|
| Back to top |
|
|
|
|
|
All times are GMT
The time now is Sat Nov 28, 2009 6:31 pm
|
|