Global Clocks in Xilinx Virtex-4

hallo everyone,

I know that global clocks allow distributing the clock signal all over
the FPGA with a low skew, but what happens, when i feed the clock e.g.
my_clk into FPGA through a normal user I/O pin?

I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
error in Xilinx ISE,  my interest ist: what will happen with my_clk?

Goes it after the input buffer still to the global clock buffer, or
wires will be routed to all the flip-flops, which my_clk connectecd to?
or somehow else?

Thanks for your answer

Regard,
Cheng

Cheng,

   I am in the middle of a Virtex4 design myself and have gone back and
forth with Xilinx about clock routing.  The documentation is very poor,
particularly with respect to the regional clock boundaries.

   As I understand it, yes you can drive a BUFG from anywhere in the
FPGA fabric if you want, however the routing is not ideal.  So, while
you still have no skew problems within the FPGA, because everything is
on the global clock net, you could have skew problems with any other
system synchronous devices in the design. (i.e. sync. srams, etc...
ddr sdrams will be source syncronous, so there is no problem here)...


   To confirm this though...  I would run ISE with your design and
follow the routing in FPGA Editor just to be POSITIVE that everything
routed as you wanted.  This is just what I recall.




uvbaz wrote:
> hallo everyone,
>
> I know that global clocks allow distributing the clock signal all over
> the FPGA with a low skew, but what happens, when i feed the clock e.g.
> my_clk into FPGA through a normal user I/O pin?
>
> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
>
> Goes it after the input buffer still to the global clock buffer, or
> wires will be routed to all the flip-flops, which my_clk connectecd to?
> or somehow else?
> 
> Thanks for your answer
> 
> Regard,
> Cheng

uvbaz wrote:

> hallo everyone,
> 
> I know that global clocks allow distributing the clock signal all over
> the FPGA with a low skew, but what happens, when i feed the clock e.g.
> my_clk into FPGA through a normal user I/O pin?
> 
> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
> 
> Goes it after the input buffer still to the global clock buffer, or
> wires will be routed to all the flip-flops, which my_clk connectecd to?
> or somehow else?
> 
> Thanks for your answer
> 
> Regard,
> Cheng
> 

You should instantiate a bufg on your clock net to make sure it gets 
onto the global routing.  Not all synthesis tools automatically insert 
that buffer, and without it, you won't get on the global clock net. 
Assuming you do have that buffer, the clock that is distributed in the 
FPGA will have low skew, but there will be a sizable offset from the 
external clock.  That may cause problems with communicating with devices 
external to the FPGA.

Ray Andraka wrote:
> uvbaz wrote:
> > I know that global clocks allow distributing the clock signal all over
> > the FPGA with a low skew, but what happens, when i feed the clock e.g.
> > my_clk into FPGA through a normal user I/O pin?
>
> You should instantiate a bufg on your clock net to make sure it gets
> onto the global routing.  Not all synthesis tools automatically insert
> that buffer, and without it, you won't get on the global clock net.
> Assuming you do have that buffer, the clock that is distributed in the
> FPGA will have low skew, but there will be a sizable offset from the
> external clock.  That may cause problems with communicating with devices
> external to the FPGA.

Also, the sizable offset will probably change every time you recompile
the project.

Alan Nishioka

Some FPGA's have PLL's that can be programmed to compensate for this offset.

"Ray Andraka" <ray@andraka.com> wrote in message 
news:V7J3h.10344$tH2.5255@newsfe20.lga...
> uvbaz wrote:
>
>> hallo everyone,
>>
>> I know that global clocks allow distributing the clock signal all over
>> the FPGA with a low skew, but what happens, when i feed the clock e.g.
>> my_clk into FPGA through a normal user I/O pin?
>>
>> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
>> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
>>
>> Goes it after the input buffer still to the global clock buffer, or
>> wires will be routed to all the flip-flops, which my_clk connectecd to?
>> or somehow else?
>>
>> Thanks for your answer
>>
>> Regard,
>> Cheng
>>
>
> You should instantiate a bufg on your clock net to make sure it gets onto 
> the global routing.  Not all synthesis tools automatically insert that 
> buffer, and without it, you won't get on the global clock net. Assuming 
> you do have that buffer, the clock that is distributed in the FPGA will 
> have low skew, but there will be a sizable offset from the external clock. 
> That may cause problems with communicating with devices external to the 
> FPGA. 

Any DLL or PLL can compensate away the clock delay between its two
inputs (same as an op-amp can compensate away any voltage difference
between its two inputs), but you cannot mystically compensate away the
dalay between the chip pin and the DLL/PLL input.
Peter Alfke, Xilinx Applications

On Nov 6, 5:47 pm, "Rob" <robns...@frontiernet.net> wrote:
> Some FPGA's have PLL's that can be programmed to compensate for this offset.
>
> "Ray Andraka" <r...@andraka.com> wrote in messagenews:V7J3h.10344$tH2.5255@newsfe20.lga...
>
> > uvbaz wrote:
>
> >> hallo everyone,
>
> >> I know that global clocks allow distributing the clock signal all over
> >> the FPGA with a low skew, but what happens, when i feed the clock e.g.
> >> my_clk into FPGA through a normal user I/O pin?
>
> >> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
> >> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
>
> >> Goes it after the input buffer still to the global clock buffer, or
> >> wires will be routed to all the flip-flops, which my_clk connectecd to?
> >> or somehow else?
>
> >> Thanks for your answer
>
> >> Regard,
> >> Cheng
>
> > You should instantiate a bufg on your clock net to make sure it gets onto
> > the global routing.  Not all synthesis tools automatically insert that
> > buffer, and without it, you won't get on the global clock net. Assuming
> > you do have that buffer, the clock that is distributed in the FPGA will
> > have low skew, but there will be a sizable offset from the external clock.
> > That may cause problems with communicating with devices external to the
> > FPGA.

Rob wrote:

> Some FPGA's have PLL's that can be programmed to compensate for this offset.
> 


This is not entirely true.  The DCM will phase match the internal signal 
to the clock presented to it, but that does not compensate for the clock 
delay introduced by routing from a general purpose input.  You need a 
feed back mechanism for that delay in order to automatically compensate.

That said, the Virtex4 DCM does allow the user to program a fixed phase 
offset, or for the FPGA design to diddle the offset in a variable mode. 
  A user could add an offset to compensate for the 'typical' delay, or 
tweak that offset till it "works", however this gets into dangerous 
territory since that offset compensation does not track the actual 
delays encountered on that route.  A sophisticated user might be able to 
use the DCM variable offset to train on the clock signal to get 
something that would autocalibrate, but it isn't something I'd generally 
recommend for the V4 because there are better ways to handle it.  The V4 
offers you the idelay elements on each pin that you can use for training 
for data alignment based on either a training sequence or a forwarded 
clock. In that case, a training circuit adjusts the delay on the data 
path inputs to center them on the active clock edges.  It is primarily 
intended for high data rate clock-forwarded interfaces.  The other 
option might be to use a clock capable I/0 and the regional or local 
clocking, which gives a way to get in a clock for clocking a relatively 
small amount of local logic, and then resynchronizing the data to your 
global clock domain inside the FPGA.

Peter,

>but you cannot mystically compensate away the
> dalay between the chip pin and the DLL/PLL input.

Why not?  I've done this before.  Perhaps we are talking about different 
things.  If data and clock arrive at the FPGA concurrently, and I want the 
input flop on the data to be clocked by a global clock generated by a PLL, 
not the clock coming into the device, compensation (phase angle) has to be 
adjusted to account for clock network delays.  These delays are known and 
can be easily compensated for by the hardware, so nothing is done 
mystically.

Thank you,
Rob



"Peter Alfke" <alfke@sbcglobal.net> wrote in message 
news:1162864709.366762.172700@b28g2000cwb.googlegroups.com...
> Any DLL or PLL can compensate away the clock delay between its two
> inputs (same as an op-amp can compensate away any voltage difference
> between its two inputs), but you cannot mystically compensate away the
> dalay between the chip pin and the DLL/PLL input.
> Peter Alfke, Xilinx Applications
>
> On Nov 6, 5:47 pm, "Rob" <robns...@frontiernet.net> wrote:
>> Some FPGA's have PLL's that can be programmed to compensate for this 
>> offset.
>>
>> "Ray Andraka" <r...@andraka.com> wrote in 
>> messagenews:V7J3h.10344$tH2.5255@newsfe20.lga...
>>
>> > uvbaz wrote:
>>
>> >> hallo everyone,
>>
>> >> I know that global clocks allow distributing the clock signal all over
>> >> the FPGA with a low skew, but what happens, when i feed the clock e.g.
>> >> my_clk into FPGA through a normal user I/O pin?
>>
>> >> I have set  XIL_PLACE_ALLOW_LOCAL_BUFG_ROUTING to 1, to ignore the
>> >> error in Xilinx ISE,  my interest ist: what will happen with my_clk?
>>
>> >> Goes it after the input buffer still to the global clock buffer, or
>> >> wires will be routed to all the flip-flops, which my_clk connectecd 
>> >> to?
>> >> or somehow else?
>>
>> >> Thanks for your answer
>>
>> >> Regard,
>> >> Cheng
>>
>> > You should instantiate a bufg on your clock net to make sure it gets 
>> > onto
>> > the global routing.  Not all synthesis tools automatically insert that
>> > buffer, and without it, you won't get on the global clock net. Assuming
>> > you do have that buffer, the clock that is distributed in the FPGA will
>> > have low skew, but there will be a sizable offset from the external 
>> > clock.
>> > That may cause problems with communicating with devices external to the
>> > FPGA.
> 

Ray,

Some FPGA's do have a feed back pin to do what you are describing.  My 
original post was not meant to reference the Virtex4.  My intent was to add 
to the general discussion of clock delay and skew.

The training you mention is something that my company had done to 
automatically compensate for data / clock skew--pretty neat.

Sorry for any confusion.

Rob


"Ray Andraka" <ray@andraka.com> wrote in message 
news:mfS3h.11272$Wb2.6990@newsfe22.lga...
> Rob wrote:
>
>> Some FPGA's have PLL's that can be programmed to compensate for this 
>> offset.
>>
>
>
> This is not entirely true.  The DCM will phase match the internal signal 
> to the clock presented to it, but that does not compensate for the clock 
> delay introduced by routing from a general purpose input.  You need a feed 
> back mechanism for that delay in order to automatically compensate.
>
> That said, the Virtex4 DCM does allow the user to program a fixed phase 
> offset, or for the FPGA design to diddle the offset in a variable mode. A 
> user could add an offset to compensate for the 'typical' delay, or tweak 
> that offset till it "works", however this gets into dangerous territory 
> since that offset compensation does not track the actual delays 
> encountered on that route.  A sophisticated user might be able to use the 
> DCM variable offset to train on the clock signal to get something that 
> would autocalibrate, but it isn't something I'd generally recommend for 
> the V4 because there are better ways to handle it.  The V4 offers you the 
> idelay elements on each pin that you can use for training for data 
> alignment based on either a training sequence or a forwarded clock. In 
> that case, a training circuit adjusts the delay on the data path inputs to 
> center them on the active clock edges.  It is primarily intended for high 
> data rate clock-forwarded interfaces.  The other option might be to use a 
> clock capable I/0 and the regional or local clocking, which gives a way to 
> get in a clock for clocking a relatively small amount of local logic, and 
> then resynchronizing the data to your global clock domain inside the FPGA.
> 

I just wanted to clear up the confusion: A closed-loop compensation can
only occur between the two inputs of the DCM or PLL, I think we can all
agree on that.
The user can then introduce an open-loop correction to the DCM or PLL
inputs, with the caveats that Ray mentioned.
Peter Alfke

On Nov 6, 7:07 pm, "Rob" <robns...@frontiernet.net> wrote:
> Ray,
>
> Some FPGA's do have a feed back pin to do what you are describing.  My
> original post was not meant to reference the Virtex4.  My intent was to add
> to the general discussion of clock delay and skew.
>
> The training you mention is something that my company had done to
> automatically compensate for data / clock skew--pretty neat.
>
> Sorry for any confusion.
>
> Rob
>
> "Ray Andraka" <r...@andraka.com> wrote in messagenews:mfS3h.11272$Wb2.6990@newsfe22.lga...
>
> > Rob wrote:
>
> >> Some FPGA's have PLL's that can be programmed to compensate for this
> >> offset.
>
> > This is not entirely true.  The DCM will phase match the internal signal
> > to the clock presented to it, but that does not compensate for the clock
> > delay introduced by routing from a general purpose input.  You need a feed
> > back mechanism for that delay in order to automatically compensate.
>
> > That said, the Virtex4 DCM does allow the user to program a fixed phase
> > offset, or for the FPGA design to diddle the offset in a variable mode. A
> > user could add an offset to compensate for the 'typical' delay, or tweak
> > that offset till it "works", however this gets into dangerous territory
> > since that offset compensation does not track the actual delays
> > encountered on that route.  A sophisticated user might be able to use the
> > DCM variable offset to train on the clock signal to get something that
> > would autocalibrate, but it isn't something I'd generally recommend for
> > the V4 because there are better ways to handle it.  The V4 offers you the
> > idelay elements on each pin that you can use for training for data
> > alignment based on either a training sequence or a forwarded clock. In
> > that case, a training circuit adjusts the delay on the data path inputs to
> > center them on the active clock edges.  It is primarily intended for high
> > data rate clock-forwarded interfaces.  The other option might be to use a
> > clock capable I/0 and the regional or local clocking, which gives a way to
> > get in a clock for clocking a relatively small amount of local logic, and
> > then resynchronizing the data to your global clock domain inside the FPGA.