Choosing a Clock Input Pin for an FPGA

[electosleepy]

Hi,

I am developing a prototype board for an Artix 7 FPGA (see attached picture) and have noticed that there is more than one pin for a clock input (unlike a microcontroller). Will any global clock input be acceptable or is there a preferred pin I must use?

[langwadt]

Hi,

I am developing a prototype board for an Artix 7 FPGA (see attached picture) and have noticed that there is more than one pin for a clock input (unlike a microcontroller). Will any global clock input be acceptable or is there a preferred pin I must use?

That can be a tricky question. for general logic any clock pin will work, but if you want to use the more advanced features of the input/output pins like deserializers etc. certain a clockpin goes with certain pins

The definitive answer is to run the design through the tool and see if it fails

[uncle_bob]

Hi

There is of course the "read through several hundred pages of doc's" approach. Even then, the design wizard in Vivado is the best way to check it out. That also is becoming increasingly true for multi use pins in MCU's as well. I've seen a number of cases where the docs were wrong and the design tool had it right.

The correct answer is indeed, do the design for what goes in the FPGA first and *then* layout the board. At the very least, get all of your I/O widgets into a design before you do the layout. It seems like a painful way to do things. Finding out after the board arrives that it can't be used is a lot more pain (been there / done that ...).

Bob

[electosleepy]

I thought that might have been the case when I started to learn about the Vivado pin planning tool. Unfortunately I don't think it will be within my power to change the direction of the project.

The logic design has not been completed yet but we want to use the GTP transceivers (light blue and grey blocks within X1Y2 region). As the logic design would be presumably close to the GTP transceiver region (X1Y2) would it best to attach the clock signal to a clock pin in the X0Y2 or X1Y1 which are adjacent to the GTP transceiver region?

[langwadt]

I thought that might have been the case when I started to learn about the Vivado pin planning tool. Unfortunately I don't think it will be within my power to change the direction of the project.

The logic design has not been completed yet but we want to use the GTP transceivers (light blue and grey blocks within X1Y2 region). As the logic design would be presumably close to the GTP transceiver region (X1Y2) would it best to attach the clock signal to a clock pin in the X0Y2 or X1Y1 which are adjacent to the GTP transceiver region?

you'll have to read this: http://www.xilinx.com/support/documentation/user_guides/ug482_7Series_GTP_Transceivers.pdf

[hamster_nz]

I thought that might have been the case when I started to learn about the Vivado pin planning tool. Unfortunately I don't think it will be within my power to change the direction of the project.

The logic design has not been completed yet but we want to use the GTP transceivers (light blue and grey blocks within X1Y2 region). As the logic design would be presumably close to the GTP transceiver region (X1Y2) would it best to attach the clock signal to a clock pin in the X0Y2 or X1Y1 which are adjacent to the GTP transceiver region?

I've played with the transceivers a little bit on Spartan-6 and Artix-7. You can not use a regular fabric clock pin (or output from a PLL) to drive the transceivers. Apparently the PLLs are too jittery to give good results. If you use the transceivers, you must use an appropriate reference clock in the transceiver block, and then supply that clock to the fabric, where you can use it to drive the rest of your design.

.... however, if you don't use the IP wizards and use primitives you can supply a fabric clock to the transceiver and it does work (at least at 2.7Gb/s, with a 165MB/s clock generated by a PLL using 100MHz supplied from a global clock pin). It is however very, very troublesome, and not guaranteed by Xilinx to work. It is a "test only" feature.

Also, there are lots of restrictions on which transceivers channels can be coupled to which reference clocks, with 7-series being a lot more flexible than the old Spartan 6.

[electosleepy]

If you use the transceivers, you must use an appropriate reference clock in the transceiver block, and then supply that clock to the fabric, where you can use it to drive the rest of your design.

We do intend to use the Vivado IP wizard for what we are creating. So are you saying that the clock signal is internally generated in the transceiver block?

[hamster_nz]

Pretty much. Here is the generic structure

Transceivers are usually in blocks of two, three or four (depending on FPGA family). Each block has:

- Reference clock selection MUX. Options are usually limited to something like this:
  - a couple reference clocks
  - the reference clock from a neighboring transceiver block.
  - maybe a clock that runs the entire column of transceivers
  - and an 'unusable' option that comes from the fabric.

- That then feeds into a high-quality PLL, usually based around an LC tank that is integrated on the die. This then generated the high speed clocks.
 
- Signals from that PLL can then feed the individual transceiver channels, but only within that block of transceivers.

- Each channel also has a not-so-smart channel PLL, that is used to perform clock data recovery on any incoming data stream, using the output of the high quality PLL as a reference clock.

On 7-series this is two PLLs per block of four transceivers. On Altera Cyclone V the middle channel of a bank of three has a PLL that can act as the master for other channels in the bank (and routed to adjacent banks).

Have a look at https://github.com/hamsternz/FPGA_DisplayPort/blob/master/src/artix7/transceiver.vhd if you want to see 7-series TX implemented with primitives. The important bit for your design may be GTPE2_COMMON. It has ports that you can't make use of in the wizard:

GTGREFCLK0 - Clock Reference clock generated by the internal FPGA logic. This input is reserved for internal testing purposes only  (as per the User Guide).

There is also GTFREFCLK1 that can be used as an input for the other PLL_1 in the same block of 4.

 As others mention, see the really good documentation at http://www.xilinx.com/support/documentation/user_guides/ug482_7Series_GTP_Transceivers.pdf for full details and feel free to ask me questions.

[kendalll]

You can hedge your bets by putting the pads down for an external oscillator on the reference clock pins for the GTP transceiver. You don't have to install the oscillator in the assembly if it ends up not being needed.

[electosleepy]

Thanks for taking your time out to answer my questions. So looking at the attached picture is the GTGREFCLK1 also limited only for testing purposes as well?

[hamster_nz]

Yes. Officially you should not use it, and the IP wizard does not support it.

However I have made it work for me

[electosleepy]

So for the transceivers we will use a reference clock from a HDMI input. If the general design was to use PLL to generate the clock signal from the transceivers for the logic on the fabric, am I correct in thinking that if the design did not have an external oscillator attached to a global clock pin and if the HDMI signal was not present, the logic wouldn't work? What happens if the design has no input clock, will it wait until a HDMI signal is attached and then begin functioning?

[hamster_nz]

So for the transceivers we will use a reference clock from a HDMI input. If the general design was to use PLL to generate the clock signal from the transceivers for the logic on the fabric, am I correct in thinking that if the design did not have an external oscillator attached to a global clock pin and if the HDMI signal was not present, the logic wouldn't work? What happens if the design has no input clock, will it wait until a HDMI signal is attached and then begin functioning?

Yes, you have to somehow dynamically switch to or from the HDMI clock, and maybe use the CDR features of the transceivers too.

Transceivers only have a limited range of frequency where they work correctly. HDMI sources go from 0.250Gb/s (640x480) to 3Gb/s. (1080p, deep color). Doing this correctly is a hard problem to solve if you want to support a wide range of input formats.

A full design is quite a bit of work, with lots of different options to chew over (e.g. oversampling the HDMI data signal at low resolution, and dynamic reconfiguration of the transceiver's PLL based the received clock rate to keep it in band. This is where the discrete HDMI receivers with wide parallel interfaces shines...

[uncle_bob]

So for the transceivers we will use a reference clock from a HDMI input. If the general design was to use PLL to generate the clock signal from the transceivers for the logic on the fabric, am I correct in thinking that if the design did not have an external oscillator attached to a global clock pin and if the HDMI signal was not present, the logic wouldn't work? What happens if the design has no input clock, will it wait until a HDMI signal is attached and then begin functioning?

Hi

Normally, you will have a core of logic that runs off of a local clock. That clock *might* be phase locked to an external source. This part of the logic handles all of the things that must continue to happen with no data source present. Generally this is the side of things that communicates with the outside world.

For multiple data rate inputs, a reconfigurable system (likely a PLL) is often used. The "core" that is independent of this input system runs the rate
selection and clock detection process. Often this involves some logic to correctly guess the input clock frequency. Some FPGA's will allow reconfiguration of PLL's on the fly. Others require a reload of the image in the device. A lot depends on how far you need to stretch things. Keeping timing in line over a very wide clock range may not be practical without a re-load.

A completely different approach is to run an MCU external to the FPGA. It handles the configuration stuff. It decides what image to load in the FPGA. You use two devices. The MCU may be better suited (or not) to the higher level stuff. It also may get you out of some interesting loops associated with reloading the decision making device.

All of this is high level system design. Normally that is worked out first. You then pick the devices and design the stuff that goes in them. In the case of a FPGA, you compile and time the design against the candidate parts. Once you have a reasonable fit, you pick the device you will be using. After that you get down to board layout and fun stuff like picking which clock pin to use.

Bob

[electosleepy]

In my system I want to have a HDMI input and a HDMI output. If the MGTREFCLK pins are inputs only does that mean that I will have to use four of the differential MGT transmiter pairs for the HDMI output whereas the HDMI input will only need three differential MGT receiver pairs and one MGTREFCLK pair?

HDMI output;

TMDS DATA0
    MGTTXP0
    MGTTXN0

TMDS DATA1
    MGTTXP1
    MGTTXN1

TMDS DATA2
    MGTTXP2
    MGTTXN2

TMDS CLK
    MGTTXP3
    MGTTXN3

HDMI input;

TMDS DATA0
    MGTRXP0
    MGTRXN0

TMDS DATA1
    MGTRXP1
    MGTRXN1

TMDS DATA2
    MGTRXP2
    MGTRXN2

TMDS CLK
    MGTREFCLK0P
    MGTREFCLK0N

[uncle_bob]

Hi

Another thing to add to the list:

What sort of glue logic are you planning on having between the FPGA and the HDMI ports?

My experience with FPGA inputs and output suggests that they are best kept away from the outside world. The day to day ESD and "plug anything in anywhere / any time " issues are often not what they like putting up with. You *can* get away with some pretty terrible things (done that on a regular basis). The issue is *relying* on the ability to get away with it. I unfortunately have seen some of our customers who apparently are a lot less lucky than I am.

It's worth considering because it will impact what type of ports you need to wire up on the FPGA.

Bob

[electosleepy]

Hi,

I'm going to use a passive network for the HDMI input and a HDMI retimer/redriver for the HDMI output which is described in this document (http://www.xilinx.com/support/documentation/application_notes/xapp1077-phy-hdmi-rx-gtp.pdf). I have chosen 15kV ESD protection so it shouldn't be a problem.

[hamster_nz]

How fast do you need to drive the HDMI port? Are you after 'just' 1080p60 8bpp?

[electosleepy]

The ultimate aim is around 3.4Gb/s per TMDS pair but I am not sure if we will reach that goal with our first prototype. If only it was 1080p that we needed, it would be simpler to implement with the SERDES.