10-12-2014 04:33 PM
im using xilinx ISE 14.1 where i have data path going from 110M clk domain to 20M clk domain. virtex device
when i implement the design, some of the regs going from source (110M domain) to dest (20M domain) give setup violation.
the timing report says -
requirement - 4.545ns
datapath delay - 9.486ns //5.062ns for logic and 4.784ns for route, logic levels = 3
i have several of these
since functionality is frozen, i cant change the RTL (else i could have maybe pipelined the design a bit more). so my questions are as follows -
1) what are my options to reduce the delay and get rid of above timing violations?
2) i understand floorplanning can help in rearranging the logic, but shouldn't ISE 14.1 be doing that itself to meet timing?
3) how can floorplanning be used to meet timing? is it my manually moving the logic around using GUI or by specifying something in the UCF file?
4) since it's just a few regs going from 110M domain to 20M domain, how can i constrain them in UCF so as to meet timing? what all constraints can i look for this?
5) i usually see in xilinx user guides how to constrain a "group". but if i want to constrain just a single user defined signal going from a source to dest, how do i do that? is that even possible?any help with the syntax/example would be great ...
thanks in advance for the inputs ...
10-12-2014 09:36 PM - edited 10-12-2014 09:38 PM
I am no expert when it comes to meeting timing but just looking the numbers you have provided:
Logic Delay: 5.062ns
I cannot perceive how any amount of floorplanning or routing changes can alter the fact that your basic logic delay is greater than the requirement. That is, if your routing delay was 0ns, you would still fail timing. You could consider your functionality but you say that this is frozen, so perhaps there are other methods.
Is the 20MHz clock derived from the 110MHz clock or are they utterly asynchronous? You could use the Timing Guide to look at FROM:TO constraints (particularly using the DATAPATHONLY keyword).
How many signals are crossing this boundary - is it possible to use a FIFO for this (you may need additional logic for the FIFO control but the critical path functionality would remain the same)?
10-13-2014 12:19 AM
thanks for the reply .. i gather that the logic delay is more than the required delay. so even with floor planning, it won't help.
i just wanted to know if there are some other options/optimization setting in the tool that may help my case - like xplorer etc. or some options in MAP that I could use for my case (though i have options like LUT optimization, optimization across heirarchy etc. already checked).
also the 20M and the 110M clock are from coming from the same PLL .. so they are purely synchronous.
at the moment - i am trying to put a TIG constraint on all the failing paths to see what all paths are causing an issue.
you said use datapathonly constraint - i know it helps in neglecting the clock skew and routing delays, but how can that help my case?
10-13-2014 12:34 AM
From the Timing Closure Guide (UG612):
A Multi-Cycle path is path that is allowed to take multiple clock cycles. these types of paths are typically covered by a Period constraint by default. They may cause errors because a Period constraint is a one-cycle constraint. To eliminate these errors, place a specific Multi-Cycle constraint on the path. This removes the path from the Period constraint.
I would argue that this description applies EXACTLY to your issue. I suggest you read this section of the Timing Closure Guide a little more fully.
10-13-2014 11:21 AM
i did read the UG612 and it says DATAPATHONLY is for 2 clock domains that are unrelated.
since my 20M and 80M clocks are coming from the same PLL, would they not be related clock domains?
10-13-2014 12:13 PM
When I suggested the DATAPATHONLY keyword, I didn't know that the clocks were coming from the same PLL. However, I believe that the multicycle constraint using FROM:TO is still applicable.
The issue is that 110/20 is not an integer, so the clocks do not always have coincident edges, i.e. there is inherent skew between the clock edges. This is what needs to be taken care of (although the values seem to have mysteriously changed to 80 and 20 - which is the correct set of frequencies?).
At least, that is my understanding.
You have posts that are similar to this topic in other threads - are all of these issues somehow related?
10-13-2014 12:36 PM
ok here's the thing -
1st design - 20M and 80M o/p from the same PLL ... this design works and timing is clean (after a lot of tweaking the tool properties).
2nd design - 20M and 110M o/p from the same PLL ... this design is failing in timing.
so my questions are/were -
1) what are the best constraints to use for the 1st design, where CDC is happening b/w the 20M and 80M domain?
2) what are the best constraints to use for the 2nd design, where CDC is happening b/w the 20M and 110M domain - esp. now that you mention the skew factor. what constraint can i explore for this (apart from multi-cycle path)?
as for posting on other threads - i'm trying timing closure for the 1st time so im getting a lot of questions and trying to resolve them as i go ...
one of the questions that i had posted was - what would be the max. freq. of a design - i.e. how can i confirm that after some tweaking of the constraints, the design can work at 110M and its not that my design cannot work over 80M and im chasing an unachievable frequency for my design?
i guess some of the posts may look similar, but im trying to ask different questions so as to get different approaches
any more inputs would be greately appreciated
10-13-2014 02:17 PM
10-14-2014 09:47 AM
thanks for your inputs.
one last clarification -
when i do implement the design and i look at the PAR report, it says that for the 80M clock that i have, the "best case achievable" is 9.058ns or appx 110M. And it says the same for another clock domain (40M).
however when i do increase the PLL o/p freq to 110M, the design starts to fail.
so my question is - the "best case achievable" mentioned in the PAR report, what does that indicate? is it the max. freq for a clock domain that the tool "thinks" it can achieve? and if i am applying that freq (or something less than that), as suggested by the tool, then why would my design fail?
please do let me know ...
10-14-2014 01:51 PM
You would probably be better off directing that question at someone from Xilinx because my short answer is I don't know. My understanding is that the "best case achievable" is the best frequency reported for a given path (usually the lowest frequency achieved in the design as a whole - thereby implying that the design, as it stands in that state, can run at the frequency reported).
HOWEVER - remember that the tools are deterministic - i.e. they will always produce the same result for the same inputs. Once you change part of the design, the previously held determinism is lost, even more so if you don't fully constrain the design by LOC'ing all the resources down.
To test this, you could try either using SmartGuide to reuse the previous map and route output to guide the next iteration (as you are only changing the PLL output - the resource utilisiation should be identical so the resources can be fully reused in this way) or physically LOC all resources - you'll probably need to extract all of that BEL information from PlanAhead (as I don't think you can do it in ISE) and place it into a UCF.
The point of my previous post is - what is your design target frequency? "As fast as possible" isn't really a useful answer.