Understanding the ISE timing report

Post Reply
jbeale
Posts: 7
Joined: February 12th, 2015, 8:45 pm

Understanding the ISE timing report

Post by jbeale » February 14th, 2015, 2:21 am

I've got some simple designs working. Now I'm trying to understand the timing report:
"Design Overview -> Static Timing" which for one design says:

Design statistics: Minimum period: 3.855ns{1} (Maximum frequency: 259.403MHz)

OK, now when I comment out one module which is using the system clock 'clk' net, as follows:

Code: Select all

/*
message_rom message_rom1_A (
    .clk(clk),
    .addr(addr_q),
    .data(tx_data_string)
); 
*/
assign tx_data_string = 8'd0;  // place-holder for message ROM
and then recompile, the clock report says now I can't go as fast:
Design statistics: Minimum period: 4.748ns{1} (Maximum frequency: 210.615MHz)

I don't understand how removing logic from the design makes it slower, what am I missing? The timing report has details such as the below, but I'm not sure how to interpret this. Apparently most of my timing budget is routing, as opposed to gate delays?

Code: Select all

   Maximum Data Path at Slow Process Corner: avr_interface/serial_rx/ctr_q_3 to avr_interface/serial_rx/data_q_0 
     Location             Delay type         Delay(ns)  Physical Resource 
                                                        Logical Resource(s) 
     -------------------------------------------------  ------------------- 
     SLICE_X21Y5.BQ       Tcko                  0.430   avr_interface/serial_rx/ctr_q<5> 
                                                        avr_interface/serial_rx/ctr_q_3 
     SLICE_X22Y6.A2       net (fanout=7)        0.763   avr_interface/serial_rx/ctr_q<3> 
     SLICE_X22Y6.A        Tilo                  0.235   avr_interface/serial_rx/ctr_q<1> 
                                                        avr_interface/serial_rx/GND_6_o_GND_6_o_equal_5_o<6>11 
     SLICE_X19Y16.A5      net (fanout=14)       1.321   avr_interface/serial_rx/GND_6_o_GND_6_o_equal_5_o<6>1 
     SLICE_X19Y16.A       Tilo                  0.259   avr_interface/serial_rx/_n0093_inv1 
                                                        avr_interface/serial_rx/_n0093_inv11 
     SLICE_X12Y24.CE      net (fanout=2)        1.295   avr_interface/serial_rx/_n0093_inv1 
     SLICE_X12Y24.CLK     Tceck                 0.313   avr_interface/serial_rx/data_q<3> 
                                                        avr_interface/serial_rx/data_q_0 
     -------------------------------------------------  --------------------------- 
     Total                                      4.616ns (1.237ns logic, 3.379ns route) 
                                                        (26.8% logic, 73.2% route) 

otzen42
Posts: 46
Joined: March 1st, 2014, 2:37 pm

Re: Understanding the ISE timing report

Post by otzen42 » February 15th, 2015, 11:46 am

Every time you make a modification to your design (no matter how small), the Xilinx tools will completely reroute your entire design inside the FPGA die (it is a completely pseudo random process, repeatable only if everything stays exactly the same). The reduction in max frequency is probably just due to a poor decision made by the routing algorithm because it didn't know you wanted to see a faster speed. The ISE tools are very "lazy". They won't work to optimize your design any further than it takes to meet your timing requirements.

If you are looking to increase your max clock frequency, and want to know about how high you can feasibly go, try bumping your clock constraint to a higher frequency and rerouting. You could even try an extra high frequency (like 350MHz) and then see what it lists for a max frequency after it fails (probably the sinario in which that number is most useful), but keep in mind that things will still change a lot from route to route, so still don't expect that to always be the max. You may be able to do better, or you may never be able to do that good again.

jbeale
Posts: 7
Joined: February 12th, 2015, 8:45 pm

Re: Understanding the ISE timing report

Post by jbeale » February 15th, 2015, 1:07 pm

Thanks for that note, useful info! I also just got "100 Power Tips for FPGA Designers" by Evgeni Stavinov and it seems you can set a parameter which is a seed of a random number generator, to see if your timing can improve. Section 93 (p. 420) "Timing Closure: Tool Options" says "Cost table is a MAP and PAR option that initializes the place and route process with a seed value ranging between 1 and 100." He tried a design using each possible cost table value, 1-100 and the resulting max clock speed varied randomly, but there was 40% speed variation in total which is more than I would have guessed, it demonstrates your point about the router being "lazy".

otzen42
Posts: 46
Joined: March 1st, 2014, 2:37 pm

Re: Understanding the ISE timing report

Post by otzen42 » February 16th, 2015, 8:20 pm

Yeah, check out SmartExplorer. I believe it is the little telescope symbol on the top bar of the GUI (I always run in batch mode at the command line, so I'm not sure if that is still what the icon looks like). It will itterate through the seed values for you (if your computer can handle it it will even run multiple routes at a time). You can even have it try different MAP/PAR options if you trust it. If you are fighting a tight timing try setting "Continue on Impossible" in MAP. The same option exists in PAR, but from my experience it doesn't do much except make it take longer before it fails.

embmicro
Site Admin
Posts: 834
Joined: March 24th, 2013, 12:45 pm

Re: Understanding the ISE timing report

Post by embmicro » February 22nd, 2015, 12:27 pm

SmartExplorer is an awesome tool and I've used it on numerous occasions. However, I really recommend trying to fix your design before resulting to using SmartExplorer since the results are very fragile. If you make any changes to your design (even the slightest) it is likely the strategy that worked before will no longer work. Instead adding pipeline stages or simplifying the logic will be much more robust. If you have a finalized design and it's pretty close to meeting timing, then SmartExplorer is great for closing the small gap.

Post Reply