1. Home
  2. Field-Programmable Gate Arrays
  3. Need advice to help improve timing on V4 FX

Need advice to help improve timing on V4 FX

Hello,

I can't meet the following constraint after playing around w/ some synthesis and implementation settings. Any specific advice as it relates to this delay path?

I'm also a bit unsure how it's calculating this path. The signals are connected as follows:

fifo_full -> [combinational logic] -> usr_tx_ack -> next_st (combinational logic) -> curr_st (register)

Any ideas why it's reporting the path this way?

Thanks,

-Brandon

================================================================================ Timing constraint: TS_clkgen_ifclk200 = PERIOD TIMEGRP "TG_clkgen_ifclk200" 5 ns HIGH 50%;

9757 items analyzed, 50 timing errors detected. (50 setup errors, 0 hold errors) Minimum period is 5.630ns.

-------------------------------------------------------------------------------- Slack: -0.630ns (requirement - (data path - clock path skew + uncertainty)) Source: ctrl_inst/curr_st_FFd4 (FF) Destination: ctrl_inst/fifo_inst/BU2/U0/gen_as.fgas/ normgen.memblk/mem1nc.coreinst/BU1023 (RAM) Requirement: 5.000ns Data Path Delay: 5.435ns (Levels of Logic = 3) Clock Path Skew: -0.135ns Source Clock: clkgen_ifclk200 rising at 0.000ns Destination Clock: clkgen_ifclk200 rising at 5.000ns Clock Uncertainty: 0.060ns Timing Improvement Wizard Data Path: ctrl_inst/curr_st_FFd4 to ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/mem1nc.coreinst/BU1023 Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- Tcko 0.360 ctrl_inst/curr_st_FFd4 net (fanout=23) 0.677 ctrl_inst/curr_st_FFd4 Tilo 0.194 ctrl_inst/curr_st_Out391 net (fanout=3) 0.604 ctrl_inst/usr_tx_ack Tilo 0.195 ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/tmp_ram_rd_en1 net (fanout=18) 1.052 ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/tmp_ram_rd_en Tilo 0.194 ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/mem1nc.coreinst/BU163 net (fanout=14) 1.641 ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/mem1nc.coreinst/N1881 Trcck_ENB 0.518 ctrl_inst/fifo_inst/BU2/U0/ gen_as.fgas/normgen.memblk/mem1nc.coreinst/BU1023 ---------------------------- --------------------------- Total 5.435ns (1.461ns logic, 3.974ns route) (26.9% logic, 73.1% route)

Reply to
Brandon Jasionowski
Loading thread data ...

Maybe you're looking at the wrong path. To me it looks as if the report is about doing a FIFO write from one of your states.

Regards Marc

Reply to
jetmarc

That's what it looks like, but no path like that exists. The signal usr_tx_ack is connected to the read enable of the FIFO:

fifo_rd_en

Reply to
Brandon Jasionowski

No, it's definitely a fifo read. The fifo write path is completely unrelated to the FSM. I'm not sure why the delays are so large on this read enable path to the FIFO. Seems odd...

0.195+1.052+0.194+1.641+0.518 = 3.6 ns

Clues? Possible optimization options?

Reply to
Brandon Jasionowski

================================================================================

--------------------------------------------------------------------------------

With 73% of the delay coming from the routing, try constraining the placement. The area group constraint is easy to apply, and has helped me many times.

Also, the clock uncertainty looks low, did you add the jitter of your clock source to the period constraint? Are you running your clock through any DCMs?

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

The problem here is the long routing delay.

I'm running 8.1i, and I have been getting good results by using the timing-driven mapping, optimized for speed (optimized for area is the default). I like 'Allow Logic Optimization Across Hierarchy', too.

--
Joe Samson
Pixel Velocity
Reply to
Joseph Samson

================================================================================

--------------------------------------------------------------------------------

The clock is sourced from a DCM. Do I need to modify the constraint? I thought ISE takes care of this for me...

Reply to
Brandon Jasionowski

================================================================================

--------------------------------------------------------------------------------

I am still using EDK/ISE 8.1, so I do not know if this has changed for more recent releases. With 8.1, the timing analyzer does not take the DCMs jitter contributions into account. If you are using the FX mode of a DCM to generate a clock, the jitter can be 100s of ps.

If you have specified the jitter of your clock input to to the DCM in your period constraint, that jitter will be modified and propagated to the constraints that are created for the output of the DCM, but the jitter that is added by the DCM is not added to the constraint.

I found this out the hard way, and it was a nasty problem. I think that the jitter of the DCMs depends on full the FPGA is and/or how much power it is using. All of my smaller unit test designs would work just fine, and only when I had a very full design would I have problems, and then the only symptom was that Linux would crash with a TLB exception after a while.

I was able to work around the issue by over specifying the amount of jitter on the source clock to the DCMs to cause the output DCM clock to be properly specified. Make sure that you have a proper jitter spec on your input clock to the DCM, at 200 MHz the jitter on your oscillator is starting to take a noticeable bite out of you clock period, and so does the DCM.

Either Peter or Austin has written several articles about dealing with jitter that are available on the Xilinx web site if you search for them.

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.