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

[Morten Leikvoll]

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

 

[Austin Lesea]

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

Austin

Morten Leikvoll wrote:

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

 

[Mike Treseler]

Austin Lesea wrote:

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.

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

 

[Marc Randolph]

Austin Lesea wrote:

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

Austin

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

 

[Philip Freidin]

On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote:

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.

Have you filed a case with the hotline?

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

Probably should file a case on this too.

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.

Maybe file a case on this?

(as the synthesizer just seemed to want to apply relaxed
constraints to too many paths).

ok, I'll shut up now.

Austin

Philip

 

[Austin Lesea]

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 Freidin wrote:

On Thu, 06 Nov 2003 07:50:23 -0800, Austin Lesea <Austin.Lesea@xilinx.com> wrote:
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.

Have you filed a case with the hotline?

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

Probably should file a case on this too.

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.

Maybe file a case on this?

(as the synthesizer just seemed to want to apply relaxed
constraints to too many paths).

ok, I'll shut up now.

Austin

Philip