cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
1,534 Views
Registered: ‎09-14-2017

Timings and behavioural sim are correct but post-synthesis functional sim is not

Hi all,

 

this is my first time with timing constraints. I have defined a clock and have constrained both inputs and outputs. Nonetheless the post-synthesis functional simulation fails. I have tried to increase the min/max timings for the inputs and outputs, but i still get the wrong result.

 

Is there a cheat sheet of things that I have to check/do in order to lower as much as possible the chances of failing the post-synthesis simulation?

 

Thanks!

0 Kudos
3 Replies
Highlighted
1,504 Views
Registered: ‎06-21-2017

The first thing I would check would be the process sensitivity lists in your code.  Behavioral simulations use these lists.  Synthesis generally does not and this can lead to discrepancies between behavioral and post synthesis simulations.  The synthesis tool should generate warnings for incomplete sensitivity lists.  Check the synthesis report for these warnings.

0 Kudos
Highlighted
Guide
Guide
1,462 Views
Registered: ‎01-23-2009

Your timing constraints to Vivado describe the environment in which the FPGA is going to work. When you perform synthesis and implementation (and the design meets the timing constraints) the tool generates a netlist that will function the same as your behavioral model under the conditions described by the constraints.

 

One of the most common problems with performing post-synthesis/implementation timing simulation is that your testbench does not conform to the constraints you used for implementation.

 

For example, if you have

create_clock -name clk -period 10 [get_ports clk]

set_input_delay -clock clk          3 [get_ports A]

set_input_delay -clock clk -min 1 [get_ports A]

 

your testbench had better drive the port "clk" with a 100MHz clock and must also drive port A in such a way as to provide at least 1ns of hold time and 7ns of setup time (10-3). If not, then you are violating the timing of the input A and your behavior may not be correct.

 

In a testbench, this must be done correctly - there are lots of ways. The clock is easy

 

reg clk=0;

 

always

  #5 clk = ~clk;

 

For driving the input, though, you need to model the 1ns of hold time. There are a number of ways

 

initial

begin

   @(posedge clk);

    A <= #2 <new_value for A for first clock>;

    B <= #2 <new_value for B for first clock>;

    @(posedge clk);

    A <= #2 <new_value for A for second clock>;

    B <= #2 <new_value for B for second clock>;

    ...

end

 

Or

 

initial

begin

   @(posedge clk);

   #2;

    A =  <new_value for A for first clock>;

    B = #2 <new_value for B for first clock>;

    @(posedge clk);

    #2;

    A = <new_value for A for second clock>;

    B = <new_value for B for second clock>;

    ...

end

 

(or a variety of other ways)

 

But, however you do it, you need to make sure that

  - your constraints match what you expect on the board

  - your design meets the constraints

  - your testbench conforms to the timing specified by the constraints

 

Avrum

0 Kudos
Highlighted
1,442 Views
Registered: ‎09-14-2017

Thanks @avrumw I didn't know about that! I'll look into it. I suppose for VHDL the equivalent is 'wait after' or something like that. I gave a quick look on the internet, but seems VHDL timing constructs are not very popular.

0 Kudos