1. Home
  2. Field-Programmable Gate Arrays
  3. Crossing/muxing clocks thru TBUF mux (w/DLL "stunts")

Crossing/muxing clocks thru TBUF mux (w/DLL "stunts")

I'm doing some stunts using DLL's in a VirtexE to make different clockspeeds. I create a clock mux using BUFT's and different clocksources wich is then fed into a last DLL and then into a global clock buffer. (This is meant to be a separate clock domain with a few exceptions, and I dont care about phase relations between the domains)

I also specify a FROM:TO between the domains at a very large number (50us), cause the few signals going between the domains are not time critical, and resynced to the correct domain. (this is done properly by asynchronous set and synchronous clear and edge detector in the new domain) The FROM:TO statement specifies a kind of "timing ignore" between all the domains used by the mux.

I have problems getting the timing analyzer to analyze this correctly. I specify a new PERIOD on the signal out of the BUFG after the mux, but the analyzer ignores this and uses the large number (supposedly the FROM:TO has priority over the PERIOD attribute) even if both source and destination of the FF is in the same domain!

I have also tried the MAXDELAY and TIG attribute in between where the PERIOD attribute may cross the domains, but it still doesnt analyse this clock domain from the correct PERIOD constraint but uses the FROM:TO.

Somehow it seems difficult to really CUT the timing in a path. The TIG attribute does not work as expected.

Any ideas? Thanks

Reply to
Morten Leikvoll
Loading thread data ...

Morten,

With the FROM:TO constraints I have always found them applying to things that I did not want them to. To really get the constraint "correct" (so that it didn't want to apply it to something else), I had to use FROM:THROUGH:TO (specify the path in question).

After mucking about with this for a long time, and failing to get a reasonable result, I just pulled the constraints, and used the period constraint all alone. The multicycle through paths now did not meet timing (failed), but at least I could go and manually check each one, and "sign off" that these paths were OK none the less.

The area was also massively affected by the FROM:THOUGH:TO constraints, with very poor timing results (worse than the period constraint alone) resulting on the paths that I really cared about and larger area.....

I suppose that if I had a single clock things would have worked better, but with multiple clock domains, resynchonization circuits, and the rest of the stuff, the FROM:TO constraints just seemed to be causing me nothing but headaches (as the synthesizer just seemed to want to apply relaxed constraints to too many paths).

Aust> I'm doing some stunts using DLL's in a VirtexE to make different

Reply to
Austin Lesea

I also like a single period constraint for staic timing.

Some static timers are smart about synchronization and some aren't. Sometimes you have to check paths or break the design in two for timing and assume the synchronizer will just work.

-- Mike Treseler

Reply to
Mike Treseler

Howdy Austin,

A number of us at my office have run into situations where we'd like to use relaxed timing for one thing or another, but rarely do so for the exact reasons you outline above. If an experienced FAE can't get it to work correctly, is the customer expected to?

Honestly, this seems like something that parallels floorplanning. Or the modular design flow. Sure, Xilinx provides a way to do these things, but it is painful enough that most people can't afford the time it takes to get it working properly - so neither the customers nor Xilinx benefits. If only Xilinx would give their customers the tools to do these kinds of things easily, they'd carve out an even bigger chunk of the FPGA market for themselves. Quite honestly, with the devices growing so large, I don't see how this can be pushed aside for much longer.

Have fun,

Marc

Reply to
Marc Randolph

Have you filed a case with the hotline?

Probably should file a case on this too.

Maybe file a case on this?

ok, I'll shut up now.

Philip

Reply to
Philip Freidin

Philip,

Funny, and appreciated. No, I did not file a case. I was designing standard cell logic.....not using DC for the FPGA. ASIC designers have exactly the same problems, and there is no solution in that space either.

Austin

Philip Freid> > >Morten,

Reply to
Austin Lesea

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.