Proper/recommended method for driving clock out from FPGA

I've inherited a design at my new company where there are two source-
synchronous interfaces at 80MHz SDR.  On one interface a clock
(tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
through an IBUF, BUFG, and finally an OBUF to the pad.  These are
single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
FF1148-10.  The entire system is synchronous to tx_clk.

At my previous company, it was generally a rule of thumb to use a DDR
IOB register to regenerate the clock when sending it out from the
FPGA.  Is this typically a good rule to follow, and, if so, is this
written in some documentation?

Thanks for any help!

bwilson79@gmail.com wrote:
> I've inherited a design at my new company where there are two source-
> synchronous interfaces at 80MHz SDR.  On one interface a clock
> (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
> is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
> through an IBUF, BUFG, and finally an OBUF to the pad.  These are
> single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
> FF1148-10.  The entire system is synchronous to tx_clk.
> 
> At my previous company, it was generally a rule of thumb to use a DDR
> IOB register to regenerate the clock when sending it out from the
> FPGA.  Is this typically a good rule to follow, and, if so, is this
> written in some documentation?
> 
> Thanks for any help!
> 
Using the DDR registers is the recommended way to regenerate the clock. 
  It will be source-synchronous with the output data, provided that the 
output data is registered in the output IOBs.  This scheme removes the 
variables of BUFG delay times and fabric routing delays.  Note that your 
output rx_clk will not be phase-aligned with tx_clock.
-Kevin

<bwilson79@gmail.com> wrote in message 
news:1179435132.737655.222610@e65g2000hsc.googlegroups.com...
> I've inherited a design at my new company where there are two source-
> synchronous interfaces at 80MHz SDR.  On one interface a clock
> (tx_clk) is forwarded to the FPGA and on the other the clock (rx_clk)
> is forwarded from the FPGA.  rx_clk is generated from taking tx_clk
> through an IBUF, BUFG, and finally an OBUF to the pad.  These are
> single-ended LVCMOS25 clocks and the device is a Xilinx Virtex-4 LX80-
> FF1148-10.  The entire system is synchronous to tx_clk.
>
> At my previous company, it was generally a rule of thumb to use a DDR
> IOB register to regenerate the clock when sending it out from the
> FPGA.  Is this typically a good rule to follow, and, if so, is this
> written in some documentation?
>
> Thanks for any help!

I haven't come across specific documentation saying "do this!"

The desire to use the same structures as those that generate the data comes 
down to error budgets.  If you can guarantee that the clock and data are 
always in a valid relationship with the delivered source-synchronous 
communication channel, it doesn't matter which method you use.  Since it's 
significantly easier to deliver *matched* delays for the DDR-generated 
clock, the error budget has significantly lower uncertainty than the 
combinatorial path.

The skew can be a large factor in the overall error budget depending on the 
receiver.  While a clock edge centered precisely between the data edges 
might seem like the best solution from an oscilloscope's perspective, having 
the clock preceed the data output and encounter a route onto the receiver 
chip that's longer than the data path to the chip's innards might be a 
better match overall.

I'd suggest there's no "correct" way to cover all bases, just a "better" way 
for the specific transmit/receive pair characteristics.

Personally, I DDR all my generated clocks.

- John_H 

For my scenario it makes sense to regenerate the clock with a DDR IOB
register because I want the clock to be source-synchronous with the
data/controls.  What would be the best way to check the delay on the
clock before I implement the regeneration?  I'd like to compare this
value with the clock to pad values found in Timing Analyzer's data
sheet report for the corresponding data/controls.

If I find the outgoing clock pad in FPGA Editor and select the net
going into it and then right click the net and go to properties and
then the pins tab, the tool gives me some delay values but I'm not
100% sure how to read them.  Here is what I'm seeing:

Name                 Type        Delay(ns)
B13.O                Input        7.252ns
AD17.I               Output      Driver
BUFGCTRL_...   Input         0.757ns

Pin B13 is rx_clk and pin AD17 is tx_clk.  I'm assuming I'd just sum
the two delays to get the total routing delay for this outgoing clock,
but I wanted to double-check if that's indeed correct.  It seems it
would make sense, where the 0.757ns delay is from the driver (tx_clk)
to the input of the BUFG, and the 7.252ns is from the output of the
BUFG to the rx_clk pad.