Referring to question here: Click here, I'd like to use the 16 channel LED driver to run my 7-segment displays. I'm using a Spartan 6 LX9 FPGA to implement a 16-bit microprocessor that will take care of it all.

The development board I'm using is pretty barebone and has an onboard 100MHz clock, or perhaps I should say oscillator. What I was planning to do is slow it down to perhaps a few megahertz, then output it via a GPIO to the LED drivers and synchronize it that way with a separate verilog module.

My question is, do I have to take special care when trying to output a clock through a GPIO? Perhaps use a particular pin? I'm given to understand that the clock input is supposed to be through a predefined pin. The clock could be slower, as it doesn't really need to be too fast.

Here's the online user manual to the development board (pretty basic): Click here.

EDIT: More information:

I'm concerned about clock skew. The chip I'm looking at writes at every positive clock edge. What I plan to do is to divide up the clock and send it out to the chip, while the FPGA also uses the same signal to synchronize and send data to the chip serially. Timing seems to be pretty tight. A slow enough clock might be the answer though.


4 Answers 4


You can use any GPIO pin you want for output. It doesn't matter if it's balanced clock or arbitrary data.

Also, output at units of MHz shouldn't give you any trouble.

In sequential logic, there is a trend to use as little of clocks as possible. This is because clocks are very often the most important signals, as many others depend on them.

I'll try to depict here the issue of propagation delay, as projected to the thing called clock skew. Imagine you have two clocks, one derived from the other:

__/--\__/--\__/--\__/--     <- original clock
___/-----\_____/-----\      <- clock divided by 2

Note that the clock below is delayed by 1 character (that would be one flip-flop delay, which is minuscule.) It's just greatly exaggerated in the ASCII art.

But, in a black-boxed FPGA design you don't have to worry about that. It's all taken care of for you. All those worst-case timing issues are taken into account in the form of maximum clock frequency, that the design can run at.

  • \$\begingroup\$ I never mentioned 'multiplying' the clock up again. I meant creating a separate verilog module to divide the clock down and then output it through a GPIO. And yes, I'm concerned about clock skew. I was planning to use the divided clock inside the FPGA to synchronize the data going to the chip. If it was slow enough, it probably wouldn't matter. Am I correct? \$\endgroup\$
    – Shreyas
    Aug 5, 2014 at 10:35
  • \$\begingroup\$ @ShreyasVinod: You are correct. I'll edit the answer. \$\endgroup\$
    – Dzarda
    Aug 5, 2014 at 10:37
  • \$\begingroup\$ I'm not concerned about timing issues inside the FPGA. The synthesis tool is amazing and handles it well. What I'm concerned about is the clock skew to the external chip, which needs a bit of hold time for the serial data being transferred before and after the positive clock edge. \$\endgroup\$
    – Shreyas
    Aug 5, 2014 at 11:09
  • \$\begingroup\$ @ShreyasVinod: Then don't be afraid. It's just a few MHz. \$\endgroup\$
    – Dzarda
    Aug 5, 2014 at 11:16
  • \$\begingroup\$ @Dzarda - low frequency does not by itself imply that setup time requirements will be met. However, low frequency combined with driving the clocked signal(s) at the inactive edge of the clock would. For tighter situations, one sets a clock-to-out delay constraint in the FPGA tools. \$\endgroup\$ Aug 5, 2014 at 16:05

The Spartan 6 family does not have dedicated clock outputs that connect directly to a clock network.

For a slow clock, such as you are suggesting, that probably doesn't even matter, because jitter and rise/fall time differences for I/O pins are slower than the clock.

For fast clocks, the recommendation I've found is to use an I/O pin in ODDR mode to make the compiler aware that both rising and falling edges on the signal matter, and let it handle the rest automatically.


What you are proposing to do, basically, is to take the FPGA 100 MHz clock, run it through a few flip-flops to reduce its frequency, and then output the reduced frequency. Your proposed output is not, in FPGA terms, a clock. It's just another registered output. So go ahead and run it out through a GPIO pin.

You are, I think, confusing this with the need to run an FPGA clock into the chip via a special clock input pin. In this case, the pin is connected to a dedicated set of drivers within the chip which distribute the clock to all the internal points which need it (and which provide considerable capacitive load).

  • \$\begingroup\$ I understand what you're saying about it being a registered output. What I meant was that I am concerned whether the GPIOs can even switch that quickly. And I'm not sure what you need by 'run an FPGA clock into the chip via a special clock input pin'. The oscillator in onboard and already connected to the pin it should be, and I'm not really bothered about that. \$\endgroup\$
    – Shreyas
    Aug 5, 2014 at 10:31
  • \$\begingroup\$ @ShreyasVinod - Ah. Sorry about the confusion. As long as you use the development board clock you don't have to worry. If you ever do use another clock, you'll need to learn about how to hook it up. Generally, GPIO pins are good for MHz signals, and even for 10s of MHz as long as you don't try to drive too much capacitance. \$\endgroup\$ Aug 5, 2014 at 11:11

There are specific requirements for inputs that are clocks because of the way the clock is distributed throughout the FPGA fabric.

However in your case, you are just outputting a divided clock on a GPIO pin so there are no specific requirements other than those that apply to the pin anyway - ie: it's an output with certain current limits etc.

Here's a snippet from some code I wrote - it's in VHDL rather than Verilog though:

my_clk_div8: process (clk, i_enable_n)
    --- On async reset
    if (i_enable_n = '1') then
        clk125 <= '0';
        clka   <= '0';
        clkb   <= '0';
        clkc   <= '0';

    --- On clock edge. Implement 4 flipflops with last output inverted
    --- and sent to first input. Divide 100MHz by 8 to get 12.5MHz

    elsif (rising_edge(clk)) then
        clka   <= not clk125;
        clkb   <= clka;
        clkc   <= clkb;
        clk125 <= clkc;
    end if;
end process my_clk_div8;
  • \$\begingroup\$ That definitively answers the question I asked. But I'm concerned about skew. I need to use the divided clock inside the FPGA to synchronize the data going to the chip, and the chip also uses the same clock to write the data. I haven't mentioned this in the question, I'll update it now. \$\endgroup\$
    – Shreyas
    Aug 5, 2014 at 10:42
  • \$\begingroup\$ I wrote the code over a year ago so I forget why I did the division with four flip flops but it's possible I was concerned about clock skew at the time. Thus the 12.5MHz output was synchronised with the incoming clock. I'm not 100% sure though so Dzarda looks like he/she might have more info. \$\endgroup\$
    – carveone
    Aug 5, 2014 at 10:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.