UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
13,154 Views
Registered: ‎08-23-2011

reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

hi, 

 

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 ...

 

regards,

zubin.

 

 

0 Kudos
9 Replies
Mentor hgleamon1
Mentor
13,142 Views
Registered: ‎11-14-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

I am no expert when it comes to meeting timing but just looking the numbers you have provided:

 

Requirement: 4.545ns

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)?

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Explorer
Explorer
13,132 Views
Registered: ‎08-23-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

hi,

 

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?

 

z.

0 Kudos
Mentor hgleamon1
Mentor
13,129 Views
Registered: ‎11-14-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

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.

 

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Explorer
Explorer
13,110 Views
Registered: ‎08-23-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

hi hgleamon1,

 

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?

0 Kudos
Mentor hgleamon1
Mentor
13,100 Views
Registered: ‎11-14-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

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?

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Explorer
Explorer
13,098 Views
Registered: ‎08-23-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

hi,

 

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 

 

:)

 

z.

 

 

0 Kudos
Mentor hgleamon1
Mentor
13,084 Views
Registered: ‎11-14-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

1. As has been discussed in other threads, the 80 and 20 MHz clocks are not CDC as they are truly related. If you meet timing and your design works, you needn't do more than you do now.

2. Why would you exclude "multi cycle constraints" if they are the most appropriate? You have non-coincident clock frequencies and must pass data between them, so you need to tell the tools that a simple period constraint is not applicable but the data can take several "fast" clocks to get the data into the "slow" domain. I can't think of a more appropriate constraint.

Max frequency - this always crops up. You should design (in the RTL) to a target frequency. If you just want to play around you can adjust your input clock or derived clock frequencies, incrementally, until timing fails. Where timing fails is your design's max frequency limit. So, if your design passes timing with an internal frequency of 80MHz but fails at 110MHz, your design's limit is somewhere between the two.

You know your design works at a given frequency when it's constrained correctly, passes functional sim and passes timing.
----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos
Explorer
Explorer
13,072 Views
Registered: ‎08-23-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

hi hgleamon1,

 

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 ...

 

z.

0 Kudos
Mentor hgleamon1
Mentor
13,059 Views
Registered: ‎11-14-2011

Re: reg: without changing RTL, resolving setup violation using UCF/floorplanning ...

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.

----------
"That which we must learn to do, we learn by doing." - Aristotle
0 Kudos