State Machine - CASE\WHEN and glitches

Altera_Forum · ‎02-19-2013

Hi everyone, I'm a bit lost and I need your help.

In my design I'm using a state machine I coded in VHDL to control a small ALU for floating point operations.

The state machine is divided in 2 parts.

The register section, with a process(low_clk), that increments the current_instruction and some other registered values... and the combinatorial section, with a process(current_instruction), containing a long CASE\WHEN structure that drives, for every instruction counter, various output signals to control the rest of the logic, plus some IF\THEN constructs that allows me to loop some sections.

Now... the code works like a charm at RTL level.

When I simulate it at GATE level however things get extremely glitchy (not to mention when I program it with the rest of the design on my FPGA)

For example... by moving up or down a "late" istruction (for example changing a WHEN 44 into a WHEN 45) alters the behavior of the whole code, adding glitches around istruction 0-10.

I believe this may be related to the synthesis of the WHEN\CASE structure... for some reasons, the comparators triggers even when they shouldn't.

I'm not asking to anyone patient enough to read my thread to debug my code... however, could he point out if I did I any major mistake in the machine design?

Or maybe if I have to make some particular timequest costraints to make it work properly? (by now I didn't have the chance to learn that part of QII yet...)

Thanks!!!

Altera_Forum · ‎02-19-2013

I will assume you passed timing.

Before anything else I note you have put default values before case statement but then you repeated some default assignments e.g.

WHEN 6 => MAC_Advance <='0';

yet MAC_Advance is on default of '0' anyway. You need not put this line but it does not answer your issue. I am just thinking you might be misunderstanding this default issue. In fact you can remove all assignments of '0' when already in default.

Altera_Forum · ‎02-20-2013

By nature of synchronous logic, the state of combinational signals is only evaluated at clock edges. Glitches seen in the these signals at other times are meaningless.

If you intend to generate any glitch-free output signals, they need to be registered however.

At first view, the design implements a regular FSM scheme. The state variable is registered correctly. As wiith every FSM, there might be timing issues brought up by asynchronous input signals that aren't registered before entering the state machine logic.

So simple question, where do you see glitches? Are you sure they actually involve problems for design operation?

Altera_Forum · ‎02-20-2013

Thank you for the answers.

FvM:

I attached a Modelsim snapshot of the glitches, allow me explain.

The instructions from that part of the code are

--- NEXT Layer Rule
WHEN 37 => set_layer <= '1'; 
---- LOAD Bias Rule
WHEN 38 => set_bias_EN <= '1';
WHEN 39 => MAC_Advance <= '1'; 
WHEN 40 => MAC_Advance <= '0'; reset_bias_EN <= '1';

Between 37 and 38 MAC_Advance shoots and forces my accumulator to load a meaningless value.

kaz:

Yes I know there are some redundancies.

I tried to add them to remove the glitches, but as I realized they were pretty useless.

One more thing... you assumed that I passed timing.

i did, but the only thing i specified in timequest was the clock, i tought that such a simple design would work without definite timing costraints.

Maybe that's the reason I'm getting this strange behavior? If it's the case, could you suggest me how to costrain it properly?

Altera_Forum · ‎02-20-2013

MAC_Advance shows just regular behaviour of a FSM design. The "glitches" occur only shortly after clock edges and are ignored by any clock synchronous logic fed by the signal. If you are using the signal in an asynchronous design, it has to be registered to the FSM clock.

Problems like the present are a reason why many people prefer a simple FSM topology with one clocked process, where all signals are registered.