remove the setup error in timing analysis

Status
Not open for further replies.
S

syedshan

Advanced Member level 1
Joined
Feb 27, 2012
Messages
463
Helped
27
Reputation
54
Reaction score
26
Trophy points
1,308
Location
Jeonju, South Korea
Visit site
Activity points
5,134
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
 

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.
 

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.
 

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.
 


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.
 

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



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

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

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

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.
 

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?
 

mrflibble said:
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?
Click to expand...

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.



 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…