remove the setup error in timing analysis

[syedshan]

Hi all
I cannot know how to remove the setup error in the static timing analyis of the clock domain that is being generated by the MMCM...
The thing is the error occurs inside the MIG design and I am unable to remove it. or does not know how to do so...

I have traced down till the end of the error location but cannot do anything since it is being generated by MIG

 

[rberek]

In these situations, there are only a handful of things you can do.

Take a look at the placed and routed design so that you can see where the tool has placed all the slices of the Memory interface. If your FPGA is highly utilized, or sometimes just because, you may find that the Interface is spread all over the die. Then you will have to partition the design . This places location constraints on the elements of the block so they are co-located and the routing delay is decreased. Too often, people just let the tool place slices wherever it wants, and sometimes it does a crappy job. IF your FPGA is nearly full, you may want to partition the entire design. Then you can place each block in your design near its I/O and keep the slices together.

If this does not work, then you are left with slowing your design down and/or using a bigger/faster device.

r.b.

 

[syedshan]

hi rberek

hope you are doing well. I have been unable to remove those errors, hence I am learning PlanAhead now for manually doing place and route...

can you tell me the basics what should I do...although I have idea. let me share with you

Paths for end point sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[7].u_iob_dq/u_iserdes_dq (ILOGIC_X1Y4.DDLY), 2 paths
--------------------------------------------------------------------------------

hence I have to change the ILOGIC_X1Y4 position to somewhere else...but how do I choose where and which one to remove the setup error?

waiting eagerly.

 

[permute]

You haven't provided sufficient information to give a definate solution. My best guess is that you've fandangled the UCF. That you've established LOC constraints for the pads and LOC constraints for the internals (and etc...) and that the errors are a result of this. MIG has previously used a lot of LOC/RLOC constraints for the purpose of telling the tools where on the FPGA the elements of MIG should be placed for optimal routing.

If you also used the same memory clock for logic, then you might also have timing errors of your own accord. Though ILOGIC errors more often mean you have a more serious issue and should regenerate MIG with a focus on the schematic of your board.

TL;DR -- check schematics vs UCF.

 

[aruipksni]

hi rberek

hope you are doing well. I have been unable to remove those errors, hence I am learning PlanAhead now for manually doing place and route...

can you tell me the basics what should I do...although I have idea. let me share with you



hence I have to change the ILOGIC_X1Y4 position to somewhere else...but how do I choose where and which one to remove the setup error?

waiting eagerly.

can you elaborate about your setup error ?
you can just drug and drop ILOGIC, just unmarked the FIXED check box, drag it and then marked again.
however i'm not sure dragging it will be usefull, since problem may lay elsewere. usually ILOGIC is placed very close to I/O.

 

[syedshan]

thank you for your response. I am posting the error, if this helps you understand the problem.

Slack (setup path): -0.666ns (requirement - (data path - clock path skew + uncertainty))
Source: sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_oserdes_dq (FF)
Destination: sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iserdes_dq (FF)
Requirement: 1.500ns
Data Path Delay: 2.297ns (Levels of Logic = 1)(Component delays alone exceeds constraint)

Maximum Data Path at Slow Process Corner: sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_oserdes_dq to sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iserdes_dq
Location Delay type Delay(ns) Physical Resource
Logical Resource(s)
------------------------------------------------- -------------------
OLOGIC_X1Y38.OQ TosckQ 0.623 sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_oserdes_dq
sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_oserdes_dq
IODELAY_X1Y38.ODATAINnet (fanout=1) 0.170 sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/dq_oq
IODELAY_X1Y38.DATAOUTTioddDATAIN 1.372 sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iodelay_dq
sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iodelay_dq
ILOGIC_X1Y38.DDLY net (fanout=2) 0.001 sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/dq_iodelay
ILOGIC_X1Y38.CLKB Tisdck_DDLY_DDR 0.131 sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iserdes_dq
sip_uwpid_mig_ddr3_512MB/i_ddr3_des/i_mig_mmu_UWPI_top/u_memc_ui_top/u_mem_intfc/phy_top0/u_phy_data_io/gen_dq[3].u_iob_dq/u_iserdes_dq
------------------------------------------------- ---------------------------
Total 2.297ns (2.126ns logic, 0.171ns route)
(92.6% logic, 7.4% route)

however i'm not sure dragging it will be usefull, since problem may lay elsewere. usually ILOGIC is placed very close to I/O.

ok this is also a valid point. I will look into it as well. But you also share your experience.

 

[rberek]

Data Path Delay: 2.297ns (Levels of Logic = 1)(Component delays alone exceeds constraint)

That's not good. The failing path, which is a path internal to the memory interface, has a single logic element which takes ~93% of the delay. The routing delay is .171ns. Your path fails by .666ns. Therefore even if you managed to get an impossible 0ns of routing delay, you would still fail timing by .495ns. In that case, no amount of moving the logic elements will help.

You may now have to consider lowering your clock speed or using a faster device, or taking another look at your timing constraints, or think of a different way to accomplish what you are trying to accomplish. since rejigging routing won't help. The delay element that appears to be the single level of logic may not be possible to remove.

Other people may have more experience in this regard and could comment. I only took a quick look at your results and may have missed something.

r.b.

 

[mrflibble]

A requirement of 1.5 ns doesn't sound very realistic. Are you sure it shouldn't be something like 3.0 ns because you made a DDR related assumption?

 

[syedshan]

A requirement of 1.5 ns doesn't sound very realistic. Are you sure it shouldn't be something like 3.0 ns because you made a DDR related assumption?

1.5 ns is the MMCM made constraint (written in .ngc file) it is only 666.66 MHz if you invert it and virtex-6 supports upto 700 MHz ideally, one thing, secondly the maximum transfer rate of my DDR3 is 666.66 MHz. see the chart for my part of DDR3 specifically.