[SOLVED] timing violation in post route simulation......

[dipin]

hi,
i am using ise design suit.
when i do behavioral simulation my output is coming with a latency of 9 clockcycle(what ever be the clock frequency) .
but in my post route simulation output is coming after 10 clock cycle(100 mhz). so how can i fix this ???

also output is appearing in -ve half cycle when there is no clock transition.????(i am using posedge clock)

i also noticed that if i decrease the frequency (50 mhz) then output is coming in 10th clock cycle. little decrease in the delay??

Also my outputs are correct but the are coming in the wrong clock compared to behavioral simulation.

how can i handle this??
please anyone give me a suggestion....


thanks & regards

 

[sharath666]

If you decrease the freq. do you mean you are getting the output in the 9th clock cycle and not 10th?
You have to go through your P&R timing reports to check for violations.

 

[ads-ee]

I suspect theee is a problem in your test bench in the way you drive clock and data. If you look carefully at the transistions of clock and data you'll probably find a register is capturing data that is for the next clock cycle early due to delta delays (event scheduling).

That's my best guess without seeing any code.

 

[dipin]

HI
actually its not possible to post code.......
.**broken link removed**

this is the output wave form.
in this out must come in the rising edge of the previous clock.
but it is coming in negative edge???
how can i solve this???
if i increase the frequency , the latency will increase more...

regards

 

[ads-ee]

HI
actually its not possible to post code.......

Why not, I'm primarily interested in the testbench and the portion of the design that distributes the clock that drives the first register that gets data. If my theory is correct you've got data that is captured on the same edge it transitions.
e.g.

[FONT=Courier New]         ____      ____      ____
clk   __|    |____|    |____|    |_
      __ _________ _________ ______
din   __X___A_____X___B_____X___C__
      __ _________ _________ ______
q_bad __X___A_____X___B_____X___C__
      __ _________ _________ ______
q_ok  __X___?_____X___A_____X___B__[/FONT]

q_bad is would be the case I'm referring to where the data is output for A at the same time as din because the rising edge of clock is capturing the new state of A instead of the old value. The actual transitions should be like q_ok. I've seen this kind of behavior in brute force testbenches that just assign values to clocks and data and use # delays to wait for the next signal transition.

.**broken link removed**

There is no attachment

this is the output wave form.
in this out must come in the rising edge of the previous clock.
but it is coming in negative edge???
how can i solve this???
if i increase the frequency , the latency will increase more...

regards

Your first post claims:

when i do behavioral simulation my output is coming with a latency of 9 clockcycle(what ever be the clock frequency) .
but in my post route simulation output is coming after 10 clock cycle(100 mhz). so how can i fix this ???

A behavioral simulation has no timing information about the logic. It only knows when the clock transitions occur. A design with 999 cascaded inverters would behave in simulation exactly the same a one with 1 inverter. In both cases the simulation would show changes in the output with a 0 delay offset from changes in the input.
The post route simulation has timing information as it's has all the cells and the routing between cells. Therefore your delay in signals is due to that, and of course this corrects the 9 clock cycle latency (the probably too early capture of data at the input of the design) and results in correct operation of 10 clock cycle latency. Changing the frequency to a lower value will increase the clock period therefore the delay you are seeing with respect to the clock edges change.

i also noticed that if i decrease the frequency (50 mhz) then output is coming in 10th clock cycle. little decrease in the delay??
Also my outputs are correct but the are coming in the wrong clock compared to behavioral simulation.

This is because you don't know the difference between behavioral and post route simulation. The first has no timing information about the design beyond the clock you use. The second has full placed and routed timing delays for a specific PVT corner (or nominal values).

 

[dipin]

hi,
ads-ee is right

Why not, I'm primarily interested in the testbench and the portion of the design that distributes the clock that drives the first register that gets data. If my theory is correct you've got data that is captured on the same edge it transitions.

from my test bench to design data is coming with the delay and it is appearing at the output.

always @(posedge clk)begin
  
  if(reset) begin
     
........apply 0 to registers...............

    
  end else if( !reset ) begin
    
            temp_in_data[1][N+1:2]      <= in_data[N-1:0];
            xtemp_in_data_1[N+3:4]      <= in_data[N-1:0];
            temp_sub_result_1           <= 1;
            xa_out_data[0]              <= 0;

       if(conditions)begin
         if(conditions) begin

                     .....design......
        
         end
       end

and the test bench is

module_test();
......


initial begin;

in_data = 0;
reset =1;
#100 = 0;

#10 in_data = 32'd10000;
#10 in_data = 32'd20000;
#10 in_data = 32'd30000;
#10 in_data = 32'd40000;
#10 in_data = 32'd50000;
end

always begin
#5 clk <=~clk;
end

endmodule

waveform is in the order
output
output
temp_in_data
xtemp_in_data
in_data
clk
reset

here the temp_in_data and xtemp_in_data are the first input to the design........
in the 5th row the yellow line staying in middle is the first input. then for temp_in_data and xtemp_in_data should come in the next rising clock edge but it is coming late. so it is reflecting in the final output .so how can i avoid this delay. why this delay is coming???
if anyone know help..
regards

 

[sharath666]

Why don't you give in_data at the falling edge of clk: something like #15 in_data instead of #10?
Looks to be a delta delay issue..

 

[dipin]

hi
i had audated the test bench . but still output is same.

module sqrt_test();
  
  reg [31:0]in_data;
  
  
  reg clk;
  reg reset;
  reg [31:0]count;
  
  wire [16:0]out_data;
  wire [17:0]remainder;


  
 sqrt   U1(
            .in_data(in_data),
            .clk(clk),
            .reset(reset),
            .out_data(out_data),
            .remainder(remainder)
        
            
             );
             
            
    initial begin
      
       
    
       clk  =1;
       reset =1'b1;
       in_data =32'd0;
       
       count = 0;
     
       repeat(10) @(negedge clk);
        reset=1'b0;
        count = 40000;
       
       end
     
  always@(negedge clk) begin
  
  if(!reset) begin
  
  in_data = count;
  count = count+1;
  
  end
  
  end
  
      
  always begin
  
  #5 clk <=~clk;
  
  end

endmodule

??????
regards

 

[sharath666]

Why is in_data and count assigned under reset? Moreover 40000 will not fit in 32 bits.

 

[dipin]

hi,

Why is in_data and count assigned under reset?

1 . after reset only i wanted to take first data.

Moreover 40000 will not fit in 32 bits

2. it will fit
i will up output image .it will give more clarity
my behavoural simulated output


post route simulation output


how can i make it equal or decrease the delay of temp_in_data and Xtemp_in_data of post route simulation
regards

 

[sharath666]

Sorry about the 40000. My mistake...
It should not be a problem if there is a shift between temp_data and Xtemp_data as long as the correct values are sampled at the rising edge of clock. Xtemp_data seems to be shifted more compared to temp_data. That may actually be the case(greater d->Q or routing delays).
As has been mentioned earlier don't compare this result with your behavioral sim. Reduce the clock frequency and check whether the circuit sampling temp_data and Xtemp_data is doing so correctly. If that is fine, then it means that there is no problem with the functionality.
Now increase the clock freq and then check. If that doesn't work, then it just means that this design has not been timing closed for the increased frequency.

 

[ads-ee]

Based on your waveforms I would suspect you have a very large logic cone in front of the signals temp_in_data and xtemp_in_data. You appear to have more than 10ns worth of delay in the xtemp_in_data. It also seems like you may have made the horrible mistake of not registering your inputs and have the logic cone attached directly to the input ports of your module.

Based on the limited information you've given I doubt anyone will be able to help you. You really need to post the code you wrote between in_data and ?temp_in_data if you expect any real help. As you can't post code could you at least describe the logic that generates the xtemp_in_data. Is this signal the input to another register? (It's obvious it is not the output of a register)

My suspicion is that you didn't balance the pipeline properly and have way too much logic between your input port and the ?temp_in_data signals to run at 100 MHz. Have you determined by looking at synthesis results or using the STA tool to see how many levels of logic (LUTs) are there between the input port in_data and the signal xtemp_in_data?.

- - - Updated - - -

then it just means that this design has not been timing closed for the increased frequency.

This begs the question: Did the OP have any timing constraints for the design when they ran synthesis, placement, and route?

- - - Updated - - -

And I highly doubt this is all the logic you have between in_data and temp_in_data/xtemp_in_data_1.

---

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
end else if( !reset ) begin
    temp_in_data[1][N+1:2]      <= in_data[N-1:0];
    xtemp_in_data_1[N+3:4]      <= in_data[N-1:0];
    if(conditions)begin
       if(conditions) begin
 
                     .....design......
        
       end
     end

---

I suspect you are assigning temp_in_data and xtemp_in_data_1 a bunch of times in the "....design..." portion of the code along with in_data getting used.

I'm pretty certain your problem stems from a lack of input constraints to in_data in relation to the clock. Which is why I say you made the horrible mistake of NOT registering your inputs to the module.

- - - Updated - - -

Actually looking at your previous post #6 that has some of the input code. I don't understand how your waveform shows that the registered output temp_in_data and xtemp_in_data_1 are delayed that much unless they are heavily loaded. There is also something weird about how the delay for the registers got worse when you switched your tb to use falling edge for the data, which shouldn't have been the case.

Specifically at 120,000 ps clock edge the first in_data results in the change of xtemp_in_data_1 just before the 130,000 ps clock edge.
Then you show in post #10. The clock edge at 100,000 ps in_data is captured and you see xtemp_in_data changing after the clock ege at 110,000 ps. I can't believe this is the same netlist you are simulating or that the code snippet you posted is what you synthesized.

 

[dipin]

Hi

i didnt had a registered input. so i added it .thanks for the help ads-ee.

now both temp_in_data and xtemp_in_data had the same delay


in the bove waveform ,in_data is coming from test bench(given in #8) . and it is given to the register in the design tin_data.

from tin_data it is giving to temp_in_data and x_temp_in_data .

but problem is its again delaying .(the tin_data register in the design to
temp_in_data & xtemp_in_data

temp_in_data and xtemp_in_data are registers used in the design(first two registers in the design).when i checked the netlist they are optimized.


can i please know how this delays are coming??
is it possible to reduce this ???
this is the code

always @(posedge clk)begin
  
  if(reset) begin
   
    tin_data <=0;
    
     ............

    remainder   <= 0;
    out_data    <= 0;

    
  end else  begin
            tin_data <= in_data;
    
            temp_in_data[1][N+1:2]      <= tin_data[N-1:0];
            xtemp_in_data_1[N+3:4]      <= tin_data[N-1:0];
            temp_sub_result_1           <= 1;
            xa_out_data[0]              <= 0;

               if (condition)
                      ......design............

in this temp_in_data[1] and xtemp_in_data are the only registers i have used tin_data(input). nowhere else i have used inputs.

more over when i synthesized the design i got a maximum clock frequency of 310 mhz

so from tin_data to temp_in_data and xtemp_in_data there is a 5ns delay.
why this delay is coming??

regards

 

[sharath666]

Can you dump the timing reports from tin_data to temp_in_data and from tin_data to xtemp_in_data? This should give you an idea of what is happening..

 

[dipin]

HI

Can you dump the timing reports from tin_data to temp_in_data and from tin_data to xtemp_in_data? This should give you an idea of what is happening..

how can i do that??
can you please tell me
regards

 

[sharath666]

Load the post routed netlist in your STA tool (I am assuming primetime) and do a "report_timing" command keeping the source and destination respectively. Do a "man report_timing" at the command prompt to understand the options for this command.