Simple state machine output question

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

On 30 Okt., 07:23, TSMGrizzly <sbatt...@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? 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

On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@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.

On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
> On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@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. =A0Think for a minute about it. =A0You've got some output that is
> coming out of a flip flop. =A0If 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. =A0Processes 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. =A0Typically 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

Gabor wrote:
> 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.

> Just my 2 cents,

Me too.

 -- Mike Treseler

On Oct 30, 9:25=A0am, Gabor <ga...@alacron.com> wrote:
> On Oct 30, 7:16=A0am, KJ <kkjenni...@sbcglobal.net> wrote:
>
> > On Oct 30, 2:23=A0am, TSMGrizzly <sbatt...@yahoo.co.jp> wrote:
>
> > > In a two-process state machine with many outputs, I would like to hav=
e
> > > 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. =A0Think for a minute about it. =A0You've got some output that is
> > coming out of a flip flop. =A0If you don't want it to change values the=
n
> > 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. =A0Processes 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. =A0Typically this is accomplished by assigning defaul=
t
> > 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.

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

> =A0I 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.

>=A0In 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. =A0

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.

> 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

On Oct 30, 8:25=A0am, Gabor <ga...@alacron.com> wrote:
> What you lose in the
> clocked-only FSM is the ability to assign outputs based on
> the current state in the same process. =A0I don't think there's
> anything inherently wrong with the two process approach as
> long as you understand what you're making. =A0In 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. =A0I 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 ... =3D>
         state :=3D ... ;
    end case;
  end if;
  -- combinatorial logic after state regs:
  output <=3D 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

Andy wrote:

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

> 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

KJ wrote:

> 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

On Oct 30, 11:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
> 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