0
\$\begingroup\$

I have a design with multiple inputs and outputs that should have different bit rates, configurable at runtime. Since there are more I/Os than PLLs, I need to share some PLLs, e.g.:

  • port 1: 1 Mbps
  • port 2: 1 Mbps
  • port 3: 15 Mbps

Ideally, I'd like to route an 1 MHz clock to the output stage of ports 1 and 2, and a 15 MHz clock to the output stage of port 3. If port 2 gets reconfigured to use 15 MHz as well, the clock routing should be changed so port 2 switches to the other clock network. If instead port 3 is reconfigured to 20 MHz, the PLL driving that clock network should be reconfigured at runtime.

Is that possible with normal FPGA architectures to make clock routing elements visible to VHDL, or should I just go with generating a clock that has a high chance of being a multiple of any baud rates I want to support, and dividing it locally on each port with enables?

Improve this question
\$\endgroup\$
8
  • \$\begingroup\$ Do you need 50% duty cycle clocks? \$\endgroup\$ – Tom Carpenter Sep 10 '20 at 11:06
  • 1
    \$\begingroup\$ On Xilinx, you can set up a DCM (or PLL) with a writable port so you can keep the clock routing constant and update the multiplier on the fly. \$\endgroup\$ – user_1818839 Sep 10 '20 at 11:08
  • \$\begingroup\$ @TomCarpenter, no, the clock itself isn't routed to the outside (although that would be a nice option), so enables work -- but it means adding more logic, so more potential for errors. \$\endgroup\$ – Simon Richter Sep 10 '20 at 11:46
  • \$\begingroup\$ @BrianDrummond, yes, PLL reconfiguration is what I'd do in the case where I need a clock that doesn't yet exist. The main problem for me is sharing PLLs, because I cannot know in advance which ports have the same baud rate. I have the option of using different dividers on the same PLL to generate multiple clocks, but they'd still have to share the multiplier and I only have four output clocks per PLL, so that would be more constrained than flexible routing. \$\endgroup\$ – Simon Richter Sep 10 '20 at 11:51
  • \$\begingroup\$ How precise do you need the output to be? Why not do it like this: You have an internal high speed clock; you set up a counter; when the counter resets you update the shift register (or whatever you have in your case) for one clock cycle in order to get the next bit. To change the timing you just load a different counter value. Use something like a 100 MHz internal clock. \$\endgroup\$ – user110971 Sep 10 '20 at 12:54
0
\$\begingroup\$

Dividing clocks locally is probably going to be the most straightfoward solution. A major advantage is that the whole design will sit in one clock domain, so you don't have to worry about clock domain crossing.

Another option to consider for generating clock enables: instead of using a simple frequency divider, use a DDS-style accumulator. This provides much finer frequency resolution, at the expense of a clock cycle of jitter. But the jitter should not be a major issue if the system clock frequency is high enough. This provides much finer control vs. a simple divider at lower division factors. IMHO, this is probably the most straightforward and most flexible solution.

However, there are some other options to consider if you really want to use separate clocks. At least on Xilinx devices, you have BUFGMUX primitives that can be used to select between two input clocks. So what you could do is have, say, one "standard" clock that is provided to all channels, and one or more reconfigurable clocks that can be provided to small groups of channels. Most likely you would want to use a separate PLL to generate these other clocks so you can also change the VCO frequency if needed. In this way, you will have some additional flexibility, although unfortunately not complete flexibility as you only have 2 clock routing options for each channel. There are also a limited number of BUFGMUX sites available.

Improve this answer
\$\endgroup\$
1
  • \$\begingroup\$ Perfect, BUFGMUX sounds exactly like what I need. \$\endgroup\$ – Simon Richter Sep 20 '20 at 11:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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