Timing violation when initializing "some" FSMs and not other

[Giuseppe Marullo]

Hi,
I am designing a very simple cw keyer, and I am wondering why some
timings in reset signal is triggering timing violations.

My problem is that apparently symmetrical FSMs get warnings on one
instance while the other not.

I got timing violations when reset duration is, for example 60ns or
100ns in the testbench:

....
// Initialize Inputs
fx2_clk = 0;
paddledot <= 1'b1;
paddledash = 1'b1;
resetpin = 1;

// Wait 100 ns for global reset to finish
#60;
resetpin = 0;

60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns
period).

I got these warnings:

WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
/test002/uut/dashstate_FSM_FFd1/ $recrem<recovery>( RST:62.893 ns,
CLK:63.358 ns,991.000 ps)

WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
/test002/uut/morsestate_FSM_FFd1/ $recrem<recovery>( RST:62.958 ns,
CLK:63.370 ns,991.000 ps)

My question is: why I got the warning on dashstate and not on dotstate?
They are debouncers for the dot and dash paddle inputs and they are
identical.

I have similar problems on another FSM:
....
always @(posedge fx2_clk or posedge resetpin )
if (resetpin)
begin
// cwkeyer <= 1'b0;
// wpm_tick_trigger <= 1'b0;
morsestate <= 4'b0000;
end
else
case (morsestate)
4'b0000: begin
// init state
cwkeyer <= 1'b0;
wpm_tick_trigger <= 1'b0;
morsestate <= 4'b0001;
end
....

but not on this, that looks similar to me:

....
// WPM timer - fixed at 12 WPM at the moment
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
// wpm_tick_elapsed <= 1'b0;
// cntwpm <= 24'b0;
wpmstate <= 4'b0000;
end
else
case (wpmstate)
4'b0000: begin
wpm_tick_elapsed <= 1'b0;
cntwpm <= 24'b0;
wpmstate <= 4'b0001;
end

....


The other question is: how is supposed async reset to be properly
handled? Should I ignore the warnings?

WebISE is 10.1

TIA,

Giuseppe Marullo

PS: some snipplets of code:


....

reg [3:0] dotstate;
reg [3:0] dashstate;

....

always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
dashout <= 1'b0;
cntdash <= 4'b0;
dashstate <= 4'b0001;
end
4'b0001: begin
if (paddledash == 1'b0)
dashstate <= 4'b0010;
else
dashout <=1'b0;
end
4'b0010: begin
if (paddledash == 1'b0)
begin
cntdash <= cntdash + 1'b1;
end
if (cntdash == 4'b011)
begin
dashout <= 1'b1;
cntdash <= 4'b0;
dashstate <= 4'b0001;
end
end
endcase

always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
// dotout <= 1'b0;
// cntdot <= 4'b0;
dotstate <= 4'b0000;
end
else
case (dotstate)
4'b0000: begin
dotout <= 1'b0;
cntdot <= 4'b0;
dotstate <= 4'b0001;
end
4'b0001: begin
if (paddledot == 1'b0)
dotstate <= 4'b0010;
else
dotout <=1'b0;
end
4'b0010: begin
if (paddledot == 1'b0)
begin
cntdot <= cntdot + 1'b1;
end
if (cntdot == 4'b011)
begin
dotout <= 1'b1;
cntdot <= 4'b0;
dotstate <= 4'b0001;
end
end
endcase
....

 

[KJ]

On Dec 30 2010, 7:56 am, Giuseppe Marullo
<giuseppe.marullonos...@iname.com> wrote:

Hi,
I am designing a very simple cw keyer, and I am wondering why some
timings in reset signal is triggering timing violations.

The reason is most likely because the timing paths are not exactly the
same.

My problem is that apparently symmetrical FSMs get warnings on one
instance while the other not.

But it is likely that they have different delays.

I got timing violations when reset duration is, for example 60ns or
100ns in the testbench:
60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns
  period).

I got these warnings:

WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
    /test002/uut/dashstate_FSM_FFd1/  $recrem<recovery>( RST:62.893 ns,
    CLK:63.358 ns,991.000 ps)

WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
    /test002/uut/morsestate_FSM_FFd1/  $recrem<recovery>( RST:62.958 ns,
    CLK:63.370 ns,991.000 ps)

My question is: why I got the warning on dashstate and not on dotstate?

Most likely because the path delay from the reset pin to the
'dotstate' process is not the same as it is to the other processes and
just happens to not trigger a timing violation under the conditions
being simulated. Take a look at the paths from the reset and clock
pins to all of the loads. What you'll likely find is that the reset
paths are different delays.

They are debouncers for the dot and dash paddle inputs and they are
identical.

Identical source code...not identical implementations, the routing
delay will be different since they must be physically in different
locations in the routed design.

I have similar problems on another FSM:
...

I would imagine so if you're not handling resets properly.

The other question is: how is supposed async reset to be properly
handled? Should I ignore the warnings?

The short answer is no should not ignore this warning. The reason is
that you are not properly handling a signal that is entering a clock
domain.

The longer answer is that since you're only reporting a problem with
your reset signal, it is likely that you could get your design to work
simply because the reset signal likely does not occur very often which
could then lead you into believing that your design is correct. In
fact, it is not. If you reset it often enough over the full temp/
voltage range of the part you would find that it does not always
work. I'm assuming here that your reset signal is an input to your
design and is not synchronized to your clock. Before using that
signal anywhere in your design you must first properly synchronize
that signal by bringing it into the input of exactly one flip flop.
The output of that flip flop is potentially metastable for a short
period of time so typically one would take the output of that flop and
send it into a second flip flop. The output of that second flip flop
would then be distributed throughout your design.

You would also do well to perform static timing analysis. I'm
guessing that you might be one who thinks that running a timing
simulation proves that timing is correct. It doesn't. Only static
timing analysis is capable of showing that timing is correct.

Kevin Jennings

 

[rickman]

On Dec 30 2010, 7:56 am, Giuseppe Marullo
<giuseppe.marullonos...@iname.com> wrote:

Hi,
I am designing a very simple cw keyer, and I am wondering why some
timings in reset signal is triggering timing violations.

My problem is that apparently symmetrical FSMs get warnings on one
instance while the other not.

I got timing violations when reset duration is, for example 60ns or
100ns in the testbench:

...
                // Initialize Inputs
                fx2_clk = 0;
                paddledot <= 1'b1;
                paddledash = 1'b1;
                resetpin = 1;

                // Wait 100 ns for global reset to finish
                #60;
                resetpin = 0;

60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns
  period).

I got these warnings:

WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
    /test002/uut/dashstate_FSM_FFd1/  $recrem<recovery>( RST:62.893 ns,
    CLK:63.358 ns,991.000 ps)

WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
    /test002/uut/morsestate_FSM_FFd1/  $recrem<recovery>( RST:62.958 ns,
    CLK:63.370 ns,991.000 ps)

My question is: why I got the warning on dashstate and not on dotstate?
They are debouncers for the dot and dash paddle inputs and they are
identical.

....snip...

I assume you are running a post-layout simulation which uses special
models for the actual components in the FPGA and checks setup and hold
times on FFs. This is a poor way to verify logic and an even poorer
way to verify timing. As KJ said, you should be checking timing using
static timing analysis.

Your error is coming from the fact that your reset is going away on
the active edge of the clock. There are two ways this will mess up
your design. One is that the prop delays to various FFs is different
so that the reset will be released on different FFs on different clock
cycles possibly putting your FSMs and other logic into invalid
states. The other is that a FF can go metastable and disrupt other
logic following it also putting things into invalid states.

I try to design my logic so it will not be disturbed by a poorly timed
async reset.

Rick

 

[Giuseppe Marullo]

Rick and Kevin,
thanks for your answers.

Kevin explained very well why I may get warnings on one implementation
and not the other. Naive error.

Rick, you are right my signal goes down exactly on the rising edge of
the clock (being async, it just happened in my simulation).

I have changed how the design not to react to posedge of the reset
signal, not sure if this will solve the metastability side.
So from:

....
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
....

To:

....
always @(posedge fx2_clk)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
....

This "solved" the warnings. About metastability and such, I didn't find
much examples on how to handle the external async reset signal to
initialize FSM.

I am trying to design a simple keyer and corresponding selfchecking
testbench.

I wanted to set conditions based on the WPM speed (words per minute) and
check high level keyer behavior.

For example I would like to be sure it will always generate dots and
dashes of the set length with the desired space between them.

I need to check that pressing the dot or dashes while already operating,
will generate the corresponding dot or dash after the current operation,
acting like a sort of small buffer.

I would like to check that the sidetone (700Hz) is correctly generated
only when the output is set.

My idea is to loop from the lowest WPM to the highest WPM and check
several conditions while I implement more complex features.

I currently having big troubles learning testbenches, and 10.1 webise
complains as soon I implement concurrent tasks, so I am using also 12.4
on windows 7 64 bit and there at least the workbench operates without
errors (so far).

Don't know much about stating timing analisys, I look at waveforms and
try to automate checks, I only have webise.

I see there is a "Static Timing Report" there but there is nothing wrong
there (0 errors).

On the other side, I didn't set any constraints, I don't know what I
could ask for at them moment, is a very simple project.

Giuseppe Marullo











On 1/3/2011 11:23 PM, rickman wrote:

On Dec 30 2010, 7:56 am, Giuseppe Marullo
giuseppe.marullonos...@iname.com> wrote:
Hi,
I am designing a very simple cw keyer, and I am wondering why some
timings in reset signal is triggering timing violations.

My problem is that apparently symmetrical FSMs get warnings on one
instance while the other not.

I got timing violations when reset duration is, for example 60ns or
100ns in the testbench:

...
// Initialize Inputs
fx2_clk = 0;
paddledot<= 1'b1;
paddledash = 1'b1;
resetpin = 1;

// Wait 100 ns for global reset to finish
#60;
resetpin = 0;

60 or 100ns are exactly on the raising edge of the feeded fx2_clk (40ns
period).

I got these warnings:

WARNING:Simulator:29 - at 63.358 ns: Warning: Timing violation in
/test002/uut/dashstate_FSM_FFd1/ $recrem<recovery>( RST:62.893 ns,
CLK:63.358 ns,991.000 ps)

WARNING:Simulator:29 - at 63.370 ns: Warning: Timing violation in
/test002/uut/morsestate_FSM_FFd1/ $recrem<recovery>( RST:62.958 ns,
CLK:63.370 ns,991.000 ps)

My question is: why I got the warning on dashstate and not on dotstate?
They are debouncers for the dot and dash paddle inputs and they are
identical.

...snip...

I assume you are running a post-layout simulation which uses special
models for the actual components in the FPGA and checks setup and hold
times on FFs. This is a poor way to verify logic and an even poorer
way to verify timing. As KJ said, you should be checking timing using
static timing analysis.

Your error is coming from the fact that your reset is going away on
the active edge of the clock. There are two ways this will mess up
your design. One is that the prop delays to various FFs is different
so that the reset will be released on different FFs on different clock
cycles possibly putting your FSMs and other logic into invalid
states. The other is that a FF can go metastable and disrupt other
logic following it also putting things into invalid states.

I try to design my logic so it will not be disturbed by a poorly timed
async reset.

Rick

 

[rickman]

On Jan 5, 4:21 pm, Giuseppe Marullo <giuseppe.marullonos...@iname.com>
wrote:

Rick and Kevin,
thanks for your answers.

Kevin explained very well why I may get warnings on one implementation
and not the other. Naive error.

Rick, you are right my signal goes down exactly on the rising edge of
the clock (being async, it just happened in my simulation).

I have changed how the design not to react to posedge of the reset
signal, not sure if this will solve the metastability side.
So from:

The way to handle async inputs is to synchronize them by running the
signals through at least one FF, or if your delays are a significant
portion of your clock cycle, through two FFs serially. The major
issue is actually just that you are feeding more than one FF with an
async input. If the input changes near the clock edge, some FFs will
see it high and others low. Running the signal through a FF first
means it will not be changing on the active edge of the clock and all
subsequent FFs will see the same value on each clock. Metastability
is a more insidious problem and actually can never be eliminated, only
minimized. But running the signal through two FFs serially will most
likely reduce the probability such that you won't see it happen in
your lifetime...

Is that clear?

...
always @(posedge fx2_clk or posedge resetpin)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
...

To:

...
always @(posedge fx2_clk)
if (resetpin)
begin
//dashout <= 1'b0;
//cntdash <= 4'b0;
dashstate <= 4'b0000;
end
else
case (dashstate)
4'b0000: begin
...

This "solved" the warnings. About metastability and such, I didn't find
much examples on how to handle the external async reset signal to
initialize FSM.

You lucked into the warnings. It is not normal to see them in
simulations, but I believe you are running a post layout simulation
where the logic element models have setup and hold time checks. This
makes your simulation run a LOT slower than a standard simulation done
before layout. There is not much reason to run simulation after
layout. This is not likely to find all or even most timing errors
while static timing analysis does a much better job.

There is a lot of debate on how to best handle an async reset
release. In your case, I assume that once the circuit is reset, it
does nothing until some external input changes state, no? If that is
true, you don't need to worry about the async reset. Go back to the
first approach you used and you will be fine. The tool will use the
global set/reset signal which will save resources.

I am not so familiar with Verilog, rather VHDL. In VHDL a register
would be described by resetting it when the reset is asserted, but the
clock is active only on an edge. What you have written above may be
just fine for Verilog, you can check other examples to be sure.

I am trying to design a simple keyer and corresponding selfchecking
testbench.

I wanted to set conditions based on the WPM speed (words per minute) and
check high level keyer behavior.

For example I would like to be sure it will always generate dots and
dashes of the set length with the desired space between them.

I need to check that pressing the dot or dashes while already operating,
will generate the corresponding dot or dash after the current operation,
acting like a sort of small buffer.

I would like to check that the sidetone (700Hz) is correctly generated
only when the output is set.

My idea is to loop from the lowest WPM to the highest WPM and check
several conditions while I implement more complex features.

I currently having big troubles learning testbenches, and 10.1 webise
complains as soon I implement concurrent tasks, so I am using also 12.4
on windows 7 64 bit and there at least the workbench operates without
errors (so far).

Don't know much about stating timing analisys, I look at waveforms and
try to automate checks, I only have webise.

All FPGA design toolsets include static timing analysis. You just
have to set up the timing constraints. The simplest one is to tell
the tool your clock speed with a period constraint. That does tons.
You may also need to have constraints for input pin setup time and
output pin delay time.

I see there is a "Static Timing Report" there but there is nothing wrong
there (0 errors).

Because either there are no timing constraints to check or some
default constraint was applied and was met.

On the other side, I didn't set any constraints, I don't know what I
could ask for at them moment, is a very simple project.

I don't know that you should expect any timing problems. If your
clock is under 10 MHz it is unlikely that you have any timing errors.
If it is faster than 50 MHz, you need to be very careful to setup the
timing constraints fully.

But I don't think timing is your problem. I think you need to be much
more concerned with your code and logic. The number one rule of using
HDLs is to remember that HDL stands for Hardware Description
Language. It should be used to describe hardware. That works better,
in my opinion, if you know what hardware you want and write the code
to get that.

I plan my design by thinking or even drawing block diagrams based on
the registers. You don't need to specify the logic in detail, but
knowing where you want registers is important. Then you can write the
code to describe those registers. The logic between registers can be
written as combinatorial code or added to the register always
blocks.

It can be important to keep the clocking simple to reduce the work
required to deal with crossing clock domains. So if possible, use one
clock with enables rather than to generate slower clocks. This helps
tons with the timing analysis too.

Does that make sense? In essence, I try to keep it all simple by
thinking simply in the HDL. There may be complexity in the logic I
use to solve the problem. But describing that logic is actually
pretty simple.

Rick