IP unnecessarily using Spartan-3 DCM?

I've got some Spartan-3 IP from a vendor which uses a DCM. However,
the DCM doesn't appear to be doing anything. The DCM is wired up as
follows:

1) A global clock pin on the device drives signal CLK1, which goes
into the IP block, where it connects to DCM/CLKIN . CLK1 is not used
anywhere else in the design.

2) DCM/CLK0 drives signal CLK2

3) signal CLK2 drives an instantiated BUFG, and comes out as CLK3

4) CLK3 is connected back to DCM/CLKFB

So far, so good; this is exactly the "On-chip with CLK0 feedback"
setup shown in fig 15(a) on p23 of the datasheet (as an aside, 15(a)
shows CLKIN coming from a BUFG, which doesn't seem to be correct in
this case; it doesn't fit with the diagram on p30).

The problem is that none of the other outputs from the DCM are used:
all the clock outputs, apart from CLK0, are open.

Now, I'm a bit rusty on Xilinx, but it seems to me that this DCM is
doing nothing if the other clock outputs are unused. Is this correct?
The DCM is set for 1X operation.

Some other info:

1) CLK3 drives all the logic in the IP block

2) CLK3 is driven out of the IP block, and drives all my logic

3) My logic doesn't communicate with the IP, except via an
asynchronous FIFO. The vendor expects my side of the FIFO to be driven
with CLK3.

TIA -

Rick

"Richard Thompson" <nospam@nospam.com> schrieb im Newsbeitrag
news:hkbu119khjirll6gmjc1qa0l0diekld4p1@4ax.com...
> I've got some Spartan-3 IP from a vendor which uses a DCM. However,
> the DCM doesn't appear to be doing anything. The DCM is wired up as
> follows:
>
> 1) A global clock pin on the device drives signal CLK1, which goes
> into the IP block, where it connects to DCM/CLKIN . CLK1 is not used
> anywhere else in the design.
>
> 2) DCM/CLK0 drives signal CLK2
>
> 3) signal CLK2 drives an instantiated BUFG, and comes out as CLK3
>
> 4) CLK3 is connected back to DCM/CLKFB
>
> So far, so good; this is exactly the "On-chip with CLK0 feedback"
> setup shown in fig 15(a) on p23 of the datasheet (as an aside, 15(a)
> shows CLKIN coming from a BUFG, which doesn't seem to be correct in
> this case; it doesn't fit with the diagram on p30).
>
> The problem is that none of the other outputs from the DCM are used:
> all the clock outputs, apart from CLK0, are open.
>
> Now, I'm a bit rusty on Xilinx, but it seems to me that this DCM is
> doing nothing if the other clock outputs are unused. Is this correct?
> The DCM is set for 1X operation.
>
> Some other info:
>
> 1) CLK3 drives all the logic in the IP block
>
> 2) CLK3 is driven out of the IP block, and drives all my logic
>
> 3) My logic doesn't communicate with the IP, except via an
> asynchronous FIFO. The vendor expects my side of the FIFO to be driven
> with CLK3.
>
> TIA -
>
> Rick

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

On Fri, 25 Feb 2005 15:26:35 +0100, "Antti Lukats"
<antti@openchip.org> wrote:

>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" <nospam@nospam.com> schrieb im Newsbeitrag
news:4ffu1157bk82ksv2nb9s5sseu3215moamo@4ax.com...
> On Fri, 25 Feb 2005 15:26:35 +0100, "Antti Lukats"
> <antti@openchip.org> wrote:
>
> >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

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 Thompson wrote:
> On Fri, 25 Feb 2005 15:26:35 +0100, "Antti Lukats"
> <antti@openchip.org> wrote:
> 
> 
>>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 wrote:
>
> 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.
>

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.

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

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.

> 
> Rick

On Fri, 25 Feb 2005 07:37:44 -0800, Austin Lesea <austin@xilinx.com>
wrote:

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

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

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

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.

Austin

Richard Thompson wrote:
> On Fri, 25 Feb 2005 07:37:44 -0800, Austin Lesea <austin@xilinx.com>
> wrote:
> 
> 
>>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.
> 
> 
> I'm not sure that I understand this - are you replying to
> 
> 
>>>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.
> 
> 
> 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
> 

On Fri, 25 Feb 2005 09:34:35 -0800, Austin Lesea <austin@xilinx.com>
wrote:

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

Thanks -

Rick