IP unnecessarily using Spartan-3 DCM?

"Richard Thompson" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

the DCM works as 0 - delay buffer thats the only function it has. that is not the same "doing nothing" CLK3 is buffered (0 delay!) version of CLK1 without the DCM the phase relation of CLK3 to CLK1 would be different and dependant on routing etc.. the DCM cancels out that dependancy

Antti

In this case, there seems to be no point in having a 0-delay buffer. The only place that CLK1 is used is at the DCM's CLKIN pin, so the whole setup seems pointless to me.

There's a second issue here, which is that zeroing out a delay (if that was the IP vendor's intent) is dangerous anyway. The only place at which the delay is zeroed is at the DCM's inputs; it's not going to be 'zero' anywhere else on the die.

Rick

"Richard Thompson" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

you probably right, if there is not external to FPGA circuitry driven by CLK1 then DCM isnt needed here, could be just BUFG as well

antti

Rick,

Oh, but it is. The idea behind the feedback is to cause there to be a known phase realtionship so one can do system synchronous IO.

The timing is within the data sheet limits for the distribution over the clock tree to the IOBs.

But, I agree, with async fifo's it looks like this is just a leftover from another core that was left in.

Austin

Richard Thomps> >

First of all the point of a zero-delay buffer on a global input pin is to synchronize to a clock off-die, not inside the chip. If you don't use the clock for any IOB's you don't need this zero-delay buffer.

to

If you believe in low-skew routing resources, then the delay should also be zero every place you use CLK3, since this is one of the DCM inputs. The important place for this to be zero in this case is at your IOB flip-flops, where it can reduce the set-up time to clock.

I'm not sure that I understand this - are you replying to

If CLK3 is heavily loaded, and CLK1 is not, then surely they will have a (very) significant phase difference at the end of the die opposite the DCM?

Rick

The DCM works as a "zero-delay" clock buffer under the following (and valid) assumptions: The Global Clock buffer has a substantial (multi-ns) delay, especially on a large chip. This delay can be "eliminated" by introducing additional DCM-internal clock delay (that's what the DCM does), so that the delayed output clock edge coincided with the incoming clock edge. There is no miraculous negative delay, but it behaves as if there were, and it therefore works only on repetitive signals like clocks. The other correct assumption is that Xilinx designers have done a good job in balancing the clock tree, so that it has (almost) the same delay wherever it arrives, within a few hundred picoseconds. Good enough that there never is a hold time issue between two flip-flops with a common global clock, no matter how that global clock is routed. I agree that there is no need for a DCM in the situation mentioned in the original posting. Peter Alfke

Rick,

You have my answer associated with the right question, yes.

Further, loading does not matter as we are fully buffered everywhere. Load as much as you like, delay does not change (on the BUFG)by more than a few tens of ps.

If it did, it would make a lot of designs very hard to do, and our performance would vary far too much from design to design, and we would have to "sand-bag" our speeds files.

P&R would be more difficult, and timing analysis would take far longer. This was one of the "break-throughs" with the original Virtex: fully buffered interconnect (patented) led to huge reductions in time in the front end software tools, as well as more predictable back-end performance.

Aust> >

Thanks -

Rick