ISim Post-Route Simulation ERROR

Question

I was attempting to test a VHDL project with Isim Simulator within ISE. Behavioral simulation works fine while Post-Route produces a lot of errors of this kind:

Warning: /X_FF PULSE WIDTH High VIOLATION ON RST; Expected:= 1.794 ns; Observed:=1.369 ns.

Why this error shows up? How could I solve it? I tried to load the relative bitstream on my Basys2 board but it doesn't work. Could it be due to this simulation error? Thanks

Control Unit code:

    type state is (IDLE, INIT, LSHIFT, ADD, SUB, SETQ);
    signal curr, nxt : state := IDLE;


begin

p0: process(clock, reset_n_in)
begin
    if reset_n_in = '0' then
        curr <= IDLE;
    elsif rising_edge(clock) then
        curr <= nxt;
    end if;
end process;

fsm : process (curr, start,reset_n_in,fine_conteggio,S)
begin
--          if reset_n_in = '0' then 
--              reset_n_out <='0';
--          else
--              reset_n_out <='1';
--          end if;


        done <='0';
        en_write_Q <= '0';
        en_shift <= '0';
        en_M <= '0';
        incrementa_conteggio <= '0';
        en_write_S_A <= '0';
        carica_operando_Q <= '0';
        subtract <= '0';

        case curr is
            when IDLE =>
                if start = '1' then
                    reset_n_out <='0';
                    done <='0';                     
                    nxt <= INIT;
                else
                    nxt <= IDLE;
                end if;
                if fine_conteggio = '1' then
                    done <='1';
                    nxt <= IDLE;
                end if;

            when INIT =>
                en_M <= '1';
                en_write_S_A <= '1';
                en_write_Q <= '1';
                reset_n_out <='1';
                carica_operando_Q <= '1';
                nxt <= LSHIFT;

            when LSHIFT =>
                en_shift <= '1';
                nxt <= SUB;

            when SUB =>

                subtract <= '1';
                en_write_S_A <= '1';
                nxt <= SETQ;

            when ADD =>

                en_write_S_A <= '1';

                if fine_conteggio = '0' then
                    incrementa_conteggio <= '1';
                    nxt <= LSHIFT;
                else
                    nxt <= IDLE;
                end if;


            when SETQ =>
                en_write_Q <= '1';

                if S = '1' then
                    nxt <= ADD;
                else
                    if fine_conteggio = '0' then
                        incrementa_conteggio <='1';
                        nxt <= LSHIFT;
                    else
                        nxt <= IDLE;
                    end if;
                end if;

        end case;
end process;

Answer 1

Timing simulations are not a routine part of a VHDL-based FPGA design flow, unless:

1. you are trying to trace a suspected tool bug (unlikely!)
2. you are verifying a design that involves multiple clocks and clock-domain crossings or asynchronous external signals.
3. You are unsure of your timing constraint coverage.

Normally, in a design that follows good synchronous design practice, behavioural simulation validates the design, and static timing analysis does a far more thorough job of verification that your design meets its timing constraints than timing simulations can : ASSUMING you have correctly set your timing constraints. Some explanation why this approach works well (given valid timing constraints) here.

However it's worth knowing how to run a timing simulation. Given that the post-route simulation model approximates the actual device timing instead of the delta-cycle model, it may interact differently with the behavioral testbench.

Thus some adjustment of the testbench may be required to allow it to work equally well with behavioural and post-route models.

I don't know a good text describing how to do this, but here's my empirical approach which has helped me catch it's share of problems (and get that questioner close to his problem).

A good sign using this approach is if you can get the behavioural and post-route models to fail the testbench in the same way.

Answer 2

As already emphasized by Brian in a comment below his answer:

You need timing constraints.

Even if your professor haven't talked about yet. Only with timing constraints, the Static Timing Analyzer (STA) can do its work. Also the Place&Route algorithm honors the timing constraints and tries to find a better route between two cells and/or a placement of the logic onto cells, so that, the requested timing (e.g. clock frequency) will be met.

Your Basys2 FPGA board provides a configurable clock oscillator. You can configure it via jumpers to 25 MHz, 50 MHz or 100 MHz, as described in the board manual. The default setting is 50 MHz whereas your testbench simulates a 100 MHz clock.

The Xilinx ISE toolchain uses so called "User Constraint File", UCF for short, for specification of timing constraints. Within the Project Navigator of Xilinx ISE, you can add a UCF File via the menu Project -> New File -> Implementation Constraints File. Specify a file name and press Next. Then the new file will show up in the design hierarchy (in the left). You can edit it by double-clicking. It is just a text file.

To specify a 100 MHz clock, you have to type into the UCF file:

NET "clock" TNM_NET = "clock_group";
TIMESPEC "TS_clock" = PERIOD "clock_group" 10 ns HIGH 50%;

The first line adds all flip-flops connected to the signal clock to a (newly created) timing group clock_group. The second line then constraints this group to a specific clock frequency, here 10 ns for 100 MHz, with a specific duty cycle (here 50%). The active clock-edge is the rising-edge (HIGH). The timing specification has also a name, which must start with TS. The timing report of the STA then refers to this name.

After, you edited the UCF file, you have to run the "Implement Design" step again, so that, new constraints are applied.

To specify a 50 MHz clock with a 40% duty cycle, you would go instead:

NET "clock" TNM_NET = "clock_group";
TIMESPEC "TS_clock" = PERIOD "clock_group" 20 ns HIGH 40%;

The actual value of the duty cycle is only important, if you have both flip-flops triggered at the rising edge and other flip-flops triggered at the falling edge of the same clock. Just select 50% if not specified in a board manual.

More about timing constraints and the syntax of the UCF file, you will find in the Xilinx Constraints Guide.