Spartan-6 input data: Use data pins or GCLK?

Question

I am designing a PCB which connects to a Spartan-6 via a connector (Opal Kelly XEM board). The PCB hosts some analog components which will communicate with the FPGA (ADCs, DACs). The FPGA board itself is completely autonomous (has own clock, PLL, ...).

My input signals to the FPGA are:

1. SPI signals (MISO/MOSI/SCK) from different ICs
2. LVDS data from the ADCs (serial data) + skew matched clock to latch these data at the FPGA
3. CMOS clock signal which may be used to clock the FPGA itself or synchronize certain signals on the FPGA (maybe not used but just in case).

Currently I connected all these inputs to the FPGA data pins (e.g. L32P_0, L2N_0 and L3N_0/L3P_0, L66P_0, L66N_0 etc.)

Now I am wondering if I should connect some or all of these signals to the global clock network (GCLK), e.g. L34P_GCLK19_0, L34N_GCLK18_0, etc).

• Is it a good idea to connect any input that is/can be a clock (will be used in always @(posedge) to GCLK?
• How would I decide which signals I connect to the data pins vs. GCLK?
• What is the purpose of the global clock network (GCLK pins) and what are the advantages/disadvantages?
• Can the GCLK pins also be safely used as LVDS input (e.g. L36P_GCLK15_0 and L36N_GCLK14_0)?

Answer 1

The global clock net in an FPGA is a specially routed net. It is a 'balanced' tree which gives minimal skew between the CLBs. (That is not the same as minimal delay!).

In a lot of FPGAs the global clock net ends in a MUX who's output only goes to the clock pin of the register(s) in the CLB. In those FPGA's it is expensive (in logic and time) or impossible to use the clock for data.

New FPGAs have a lot of I/O pins operating in pairs to make a differential input or output. It is essential that you use a 'pair' for differential signals. They will definitely have a 'pair' for the global clock net as well.

For details you have to read the FPGA datasheets and prepare to reserve a few hours for that. High speed I/O works only if you give meticulous attention to those details.

Answer 2

I'd say it's not necessary to route non-clock signals to global clock network pins. In case such a signal has a high fanout you can still implement a global buffer.