Prev: what is incorrect about my usage of array with port entity?
Next: Unpredictable design
From: Weng Tianxiang on 17 Feb 2010 09:40
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
From: Andy on 17 Feb 2010 10:36
On Feb 17, 8:40 am, Weng Tianxiang <wtx...(a)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

From: Weng Tianxiang on 17 Feb 2010 10:48
On Feb 17, 7:36 am, Andy <jonesa...(a)comcast.net> wrote:
> On Feb 17, 8:40 am, Weng Tianxiang <wtx...(a)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
From: Andy on 17 Feb 2010 11:11
On Feb 17, 9:48 am, Weng Tianxiang <wtx...(a)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


From: Weng Tianxiang on 17 Feb 2010 11:11
On Feb 17, 7:36 am, Andy <jonesa...(a)comcast.net> wrote:
> On Feb 17, 8:40 am, Weng Tianxiang <wtx...(a)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




 |  Next  |  Last
Pages: 1 2 3 4 5
Prev: what is incorrect about my usage of array with port entity?
Next: Unpredictable design