«

Hi,
Sometimes, when an if statement misses a "else" statement part in a
two-process
method for a state machine, a latch-type state machine would be built.

I always wondering how the state machine is built: using all latches
for the state machine
or using only one latch for the state which misses a "else" statement
part.

Here is the code.

Process_1 : process(RESET, CLK)
begin
if RESET = '1' then
State_A <= S0;
elsif CLK'event and CLK = '1' then
State_A <= State_NS;
end if;
end process;

Process_2 : process(...)
begin
case State_A is
when S0 =>
if C01 = '1' then
State_NS <= S1;
elsif C02 = '1' then
State_NS <= S2; -- missing a "else" part
-- a latch is generated
end if;
when S1 => -- the followings are normal coding
...;

when others =>
...;
end case;
end process

I ask how the state latch S0 is generated.

Here is latch logic equation:
Latch_S0_Data <= '1';
Latch_S0_E <=

Weng

On Feb 17, 8:40*am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> Sometimes, when an if statement misses a "else" statement part in a
> two-process
> method for a state machine, a latch-type state machine would be built.
>
> I always wondering how the state machine is built: using all latches
> for the state machine
> or using only one latch for the state which misses a "else" statement
> part.

A latch type state machine is not built; the latch is only inserted
into the next state logic. A flip-flop still holds the current state.

I know the following is not the point of your post, but your example
implies that missing "else" statements generate latches.

This is not true.

Missing assignments generate latches. If a driven signal in a
combinatorial process is not assigned a value in a given execution of
the process, then the simulator has to remember what the last
assignment was. The synthesis tool generates a latch to create that
memory.

Similarly for a variable in a combinatorial process, if the variable
is read before it has been written in any given execution of that
process, a latch is created to remember the last assignment.

If I use a combinatorial process (extremely rarely in RTL), I make a
default assignment to every signal & variable driven by the process,
right up front, where it is always executed (and before any variables
are read). In the case of the next state logic, it would simply be
"state_ns <= state_a;". That way there is no need to code useless else
statements everywhere (and all the assignments that must otherwise be
included in them).

Andy

On Feb 17, 7:36*am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 8:40*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Hi,
> > Sometimes, when an if statement misses a "else" statement part in a
> > two-process
> > method for a state machine, a latch-type state machine would be built.
>
> > I always wondering how the state machine is built: using all latches
> > for the state machine
> > or using only one latch for the state which misses a "else" statement
> > part.
>
> A latch type state machine is not built; the latch is only inserted
> into the next state logic. A flip-flop still holds the current state.
>
> I know the following is not the point of your post, but your example
> implies that missing "else" statements generate latches.
>
> This is not true.
>
> Missing assignments generate latches. If a driven signal in a
> combinatorial process is not assigned a value in a given execution of
> the process, then the simulator has to remember what the last
> assignment was. The synthesis tool generates a latch to create that
> memory.
>
> Similarly for a variable in a combinatorial process, if the variable
> is read before it has been written in any given execution of that
> process, a latch is created to remember the last assignment.
>
> If I use a combinatorial process (extremely rarely in RTL), I make a
> default assignment to every signal & variable driven by the process,
> right up front, where it is always executed (and before any variables
> are read). In the case of the next state logic, it would simply be
> "state_ns <= state_a;". That way there is no need to code useless else
> statements everywhere (and all the assignments that must otherwise be
> included in them).
>
> Andy

Andy,
Good point !

Now I ask how the next state latch is generated.

Weng

On Feb 17, 9:48*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> Now I ask how the next state latch is generated.
>

The latch is not just for S0, it is for the entire state. S0 is a
value for the state register, not a register or latch itself (unless
the FSM is one-hot encoded, but even then, the other state bits would
have a corresponding latch, with the same control, but with their
normal logic as the input).

It is only latched when in S0 (with other conditions: CO1 = '0' and
CO2 = '0').
The input to the latch is the all the normal next state logic.

Andy

On Feb 17, 7:36*am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 8:40*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Hi,
> > Sometimes, when an if statement misses a "else" statement part in a
> > two-process
> > method for a state machine, a latch-type state machine would be built.
>
> > I always wondering how the state machine is built: using all latches
> > for the state machine
> > or using only one latch for the state which misses a "else" statement
> > part.
>
> A latch type state machine is not built; the latch is only inserted
> into the next state logic. A flip-flop still holds the current state.
>
> I know the following is not the point of your post, but your example
> implies that missing "else" statements generate latches.
>
> This is not true.
>
> Missing assignments generate latches. If a driven signal in a
> combinatorial process is not assigned a value in a given execution of
> the process, then the simulator has to remember what the last
> assignment was. The synthesis tool generates a latch to create that
> memory.
>
> Similarly for a variable in a combinatorial process, if the variable
> is read before it has been written in any given execution of that
> process, a latch is created to remember the last assignment.
>
> If I use a combinatorial process (extremely rarely in RTL), I make a
> default assignment to every signal & variable driven by the process,
> right up front, where it is always executed (and before any variables
> are read). In the case of the next state logic, it would simply be
> "state_ns <= state_a;". That way there is no need to code useless else
> statements everywhere (and all the assignments that must otherwise be
> included in them).
>
> Andy

Andy,
I read your post carefully and found my point stands:
"your example implies that missing "else" statements generate
latches.
This is not true. "

This is true !!! Based on your claim: Missing assignments (in a
combinational process) generate latches .

If one misses "else" (in a combinational process), it misses an
assignment statement.

Weng

On Feb 17, 8:11*am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 9:48*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
> > Now I ask how the next state latch is generated.
>
> The latch is not just for S0, it is for the entire state. S0 is a
> value for the state register, not a register or latch itself (unless
> the FSM is one-hot encoded, but even then, the other state bits would
> have a corresponding latch, with the same control, but with their
> normal logic as the input).
>
> It is only latched when in S0 (with other conditions: CO1 = '0' and
> CO2 = '0').
> The input to the latch is the all the normal next state logic.
>
> Andy

Andy,
I disagree with your point.

In the situation, at most only one latch is needed to resolve the
problem. Why full state machine?

We can safely assume the state machine is one-hot encoded.

Weng

hi,

Weng Tianxiang wrote:
> In the situation, at most only one latch is needed to resolve the
> problem. Why full state machine?
> We can safely assume the state machine is one-hot encoded.
if you have troubles infering latches,
then you can implement them directly
with a specific entity ?
it's not looking as "smart" but
removes any ambiguity from your code.

> Weng
yg

--
http://ygdes.com / http://yasep.org

On Feb 17, 9:11*am, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 17, 7:36*am, Andy <jonesa...@comcast.net> wrote:
>
>
>
> > On Feb 17, 8:40*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Hi,
> > > Sometimes, when an if statement misses a "else" statement part in a
> > > two-process
> > > method for a state machine, a latch-type state machine would be built..
>
> > > I always wondering how the state machine is built: using all latches
> > > for the state machine
> > > or using only one latch for the state which misses a "else" statement
> > > part.
>
> > A latch type state machine is not built; the latch is only inserted
> > into the next state logic. A flip-flop still holds the current state.
>
> > I know the following is not the point of your post, but your example
> > implies that missing "else" statements generate latches.
>
> > This is not true.
>
> > Missing assignments generate latches. If a driven signal in a
> > combinatorial process is not assigned a value in a given execution of
> > the process, then the simulator has to remember what the last
> > assignment was. The synthesis tool generates a latch to create that
> > memory.
>
> > Similarly for a variable in a combinatorial process, if the variable
> > is read before it has been written in any given execution of that
> > process, a latch is created to remember the last assignment.
>
> > If I use a combinatorial process (extremely rarely in RTL), I make a
> > default assignment to every signal & variable driven by the process,
> > right up front, where it is always executed (and before any variables
> > are read). In the case of the next state logic, it would simply be
> > "state_ns <= state_a;". That way there is no need to code useless else
> > statements everywhere (and all the assignments that must otherwise be
> > included in them).
>
> > Andy
>
> Andy,
> I read your post carefully and found my point stands:
> "your example implies that missing "else" statements generate
> latches.
> This is not true. "
>
> This is true !!! Based on your claim: Missing assignments (in a
> combinational process) generate latches .
>
> If one misses "else" (in a combinational process), it misses an
> assignment statement.
>
> Weng

I think the other Andy's point is that missing an "else" clause in a
combinatorial process is a special case of the more general "missing
an assignment."

-a

On Feb 17, 9:50*am, Andy Peters <goo...@latke.net> wrote:
> On Feb 17, 9:11*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 17, 7:36*am, Andy <jonesa...@comcast.net> wrote:
>
> > > On Feb 17, 8:40*am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > > Hi,
> > > > Sometimes, when an if statement misses a "else" statement part in a
> > > > two-process
> > > > method for a state machine, a latch-type state machine would be built.
>
> > > > I always wondering how the state machine is built: using all latches
> > > > for the state machine
> > > > or using only one latch for the state which misses a "else" statement
> > > > part.
>
> > > A latch type state machine is not built; the latch is only inserted
> > > into the next state logic. A flip-flop still holds the current state.
>
> > > I know the following is not the point of your post, but your example
> > > implies that missing "else" statements generate latches.
>
> > > This is not true.
>
> > > Missing assignments generate latches. If a driven signal in a
> > > combinatorial process is not assigned a value in a given execution of
> > > the process, then the simulator has to remember what the last
> > > assignment was. The synthesis tool generates a latch to create that
> > > memory.
>
> > > Similarly for a variable in a combinatorial process, if the variable
> > > is read before it has been written in any given execution of that
> > > process, a latch is created to remember the last assignment.
>
> > > If I use a combinatorial process (extremely rarely in RTL), I make a
> > > default assignment to every signal & variable driven by the process,
> > > right up front, where it is always executed (and before any variables
> > > are read). In the case of the next state logic, it would simply be
> > > "state_ns <= state_a;". That way there is no need to code useless else
> > > statements everywhere (and all the assignments that must otherwise be
> > > included in them).
>
> > > Andy
>
> > Andy,
> > I read your post carefully and found my point stands:
> > "your example implies that missing "else" statements generate
> > latches.
> > This is not true. "
>
> > This is true !!! Based on your claim: Missing assignments (in a
> > combinational process) generate latches .
>
> > If one misses "else" (in a combinational process), it misses an
> > assignment statement.
>
> > Weng
>
> I think the other Andy's point is that missing an "else" clause in a
> combinatorial process is a special case of the more general "missing
> an assignment."
>
> -a

No.

Here is another example showing Andy's point is not correct:

Here is the code.
Process_1 : process(RESET, CLK)
begin
if RESET = '1' then
State_A <= S0;
elsif CLK'event and CLK = '1' then
State_A <= State_NS;
end if;
end process;

Process_2 : process(...)
begin
case State_A is
when S0 =>
if C01 = '1' then
State_NS <= S1;
elsif C02 = '1' then
State_NS <= S2;
else
-- here an assignment statement is missing, but it doesn't
generate latch version !!!
-- it is treated as a null statement.
end if;
when S1 => -- the followings are normal coding
...;
when others =>
...;
end case;
end process;

If you have a compiler of VHDL, try to compile it to see what happens
with "else" and without "else".

Weng

I agree with Andy. The important thing is whether there is a path
through the code that does not assign one of the outputs. This is
often due to a missing else, but it is the assignment that matters.

You can have a missing else without a missing assignment, and there is
no latch. All that is required is that you have an unconditional
assignment to the outputs also.

You can have a missing assignment without a missing else, and there is
a latch. The else may be present, but assign only a subset of the
outputs.