I'm using all the four phase-out signals from a DCM (0, 90, 180 and 270 degrees offset) to each clock a single D-Flipflop. I want these flip-flops to be placed and routed as close (delay-wise) to the DCM outputs as possible. But I can't figure out how to set up a constraint for that: timing constraints only seem to work on pins, flipflops, pads and latches. Can anyone suggest how to get PAR to put the FFs as close to the DCM, with the delays for these 4 nets as close to each other as possible ?
"Paul Boven" schrieb im Newsbeitrag news: snipped-for-privacy@blaat.sara.nl...
Just use a LOC constraint. Gives you maximum control with minimum trouble. But you can define a timing group for these four clocks and define a max. delay. Also a max skew constraint is probably a good idea. Have a look at the xapps, there a several ones discussing clock/data recovery at very high data rate by doing exactly what you want to do.
One alternative is: Lock each clock output to a pre-defined BUFGMUX location. Then, describing each FFs in a different block (per different clock domain), assign area constraints as to place it as close as possible.
Another: After you define a TNM group, specify the maximum delay (never tried this one, but it should be ok in terms of contraints)
And another: Application-dependent, i.e. if you are trying to implement a QDR or somth. like this, then there is some very nice xapp for that.
I've been doing LOC so far. But there are 4 FFs to place around the DCM, probably 10 or more locations that might qualify depending on what routing resources are available from DCM to CLBs. The number of permutations gets a bit big, especially when scaling up to 4 DCMs and 16 flipflops. So, being lazy, I was hoping to use the software to figure out the best placement for me.
Yes, that's what I'm trying to do. Just don't know the proper syntax/commands yet.
Ah, good one that I should have thought of myself. Xapp 225 seems a good place to start.
That wouldn't work: I have 4 DCMs with 4 outputs each, which would require 16 BUFGMUX, but there are only 8 of them. And using a BUFGMUX seems a bit overkill for a net that only connects to one flipflop.
I've figured out how to define TNM or TIMEGRP entities, but not how to apply constraints like maxdelay or maxskew to them. Any hints?
My application is a reciprocal frequency counter. There will be two input signals: a 100MHz reference clock, and an unknown input. I want to measure the time between two rising edges of the input signal as accurately as possible. The input signal is used as the data input to 16 D-flipflops. Each flip flop is clocked from a different DCM. The first DCM provides 0, 90, 180 and 270 degrees of my original 100MHz reference. Hence, it quadruples my resolution. The second DCM has a fixed phase offset of 32 (45 degrees) and produces clock signals at 45, 135, 225 and
315 degrees, doubling my resolution once more: Using all four DCMs gives me the ability to determine where the rising edge of the input signal falls in relationship to the 100MHz input with a resolution of 22.5 degrees or 1/16th of a full phase. This corresponds to a resolution of
625ps, or an equivalent reference of 1.6 GHz.
For this to work, I need to make sure that the delay from the DCM outputs to all the clock inputs on the flipflops are as equal and as low as possible.
All the (single wire) nets that connect a DCM output to its flipflop, I've named "net_DCMx_y" where x = the number of the DCM (0 - 3) and Y the phase-shift of the signal. I've tried setting "net net_DCM* maxdelay=1ns;" in my UCF. I'm not sure whether it does very much: Mostly it just happily reports that it violated 6 out of 8 timing constraints.
Maxskew is related to a single net, and is without meaning on nets that consist of a single wire. If I could somehow constrain the differences in delay of all the net_DCM* to be small, that would be very helpfull. Perhaps this should be possible with TNM or TIMEGRP, but I haven't been able to figure out how to use those.
I have no idea how reliably the software handles this, but there is an attribute that tags a net's source as the starting point for time specs, TPSYNC . Maybe with this (documented in Xilinx's Constraints guide) you can spec a path that starts at the DCM, and ends at each FF. You may want to assign each FF to its own group, and have 16 separate time specs, to help you isolate problems.
This is a very interesting application. I've done something similar with an Actel Axcelerator and 4 clock phases. Each phase was skewed by 1ns from the next phase. I ran the internal PLLs with a 62.5MHz input and set the PLLs up for a 4X operation and an output of 250MHz. This gave an overall system of 4 clock phases at 250MHz with 1ns between phases. With 4 phases, the programmed precision of delays was adequate. The Actel devices had a resolution of 130ps step sizes for programmed delay. This application wound up being very successful, though.
One thing to watch, though, is the jitter on the clock input line. If multiple modules are driven from the same clock, each module may have a slightly different jitter value. Since you're depending on pretty precise alignments between phases, these values may affect overall precision.
I would be very interested in hearing of your progress. I am looking at implementing an enhanced version of our current design using more clock phases.
Hi Paul, You might want to look into directed routing for your application. With this you use FPGA editor to manually route the signals and place the FFs and DCMs exactly where you want them. You then use Tools->Directed Routing (or something like that!) to generate constraints that you add to your UCF file. This makes the P&R tool route the signals the same way every time. (Or at least it should do!) Once you get the hang of it, it's just about bearable! You'll also impress your colleagues with reams of gobbledygook in your UCF file. I recently spent a week or two doing this, and, although my monitor now has several dents, I just about remained sane. Just. YMMV, but be aware that the Synplify/ISE combination that I use has a bad habit of changing the net names, seemingly depending on the day of the week. This screws up your UCF constraints, of course. A friend of mine said he only does directed routing on Mondays, for this very reason! ;-) Cheers, Syms.
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.