Xilinx Virtex-4 Clock Multiplexer Inputs

Hi all,

I'm currently developing a PCB featuring a Xilinx Virtex-4 device. Unlinke the Virtex-II series they now offer the possibility to route various clock signals to several domains on the FPGA and select them locally by specific clock multiplexer inputs. Because of the restricted amount of available pins on the device I selected (Virtex-4 FX40 with 352 user I/Os) I would like to use just one clock input on each side of the FPGA, thereby saving clock multiplexer inputs which I can use as normal GPIOs, and use an external clock multiplexer instead for my 3 clocks. Has anyone made experience with such or similar solution? Has anyone used an external clock multiplexer device for frequencies up to 500 MHz, yet? Is there any recommendation which chip I could use for this application in terms of jitter, etc.? And by the way... is my approach advisable, at all?

Any comments are appreciated.

Regards Elmo

Reply to
Elmo Fuchs
Loading thread data ...

What I find amazing is that you feel the need to sacrifice a chip's normal clock architecture just for the sake of gaining a few more I/O pins. If you are so tight on your design fit that you are approaching nearly 100% I/O utilization on the FPGA then you better begin looking at another approach.

First off let me describe the issues of designing to the limit of a part. It is always wise to reserve some number of I/O pins on a design. These are needed for several very important reasons. One is the need to allow for some additional expansion in case you discover the need for bring a bit more of the outside world in or to bring out some controls for other devices or logic. With new designs it is very often that even with the best design intentions one can end up overlooking the need for additional stimulous going in or status coming out. Second there the the huge benefit of having some extra I/Os on test points that you can temporarily connect into internal parts of the FPGA circuit to support the debug and design validation process. Big FPGAs with lots of complex embedded circuitry can be a challenge to debug and the visibility pins will be a godsend if and when you need them. Lastly there is a common habit formed by FPGAs that once you lock the pins and commit to the PC board connectivity subsequent changing of the internal logic definition in a big way can sometimes make it next to impossible to keep the same pin allocation. A few spare pins on each side or within each I/O block of the chip can often allow a re-fit to work if you free one or two I/Os from their previously locked pins.

When considering how to move away from a design that is targeting nearly 100% utilization you can consider a number of approaches. Look at partitioning the design in a manner that you could put it into pair of smaller devices. On the other hand there is also the possibility to move to a larger FPGA device as well. A third thing to look at is if a considerable number of I/O pins can be saved by using some simple fixed logic devices at the periphery of the chip. A simple example is the parallel to serial conversion strategy that could be implemented with cheap shift registers to support many slow GPIOs with a few I/O pins at the FPGA. It is relatively easy to design FPGA logic that can free run a shift in or shift out process to keep the external GPIO states in synch with internal nodes with a modest latency.

Good Luck

- mkaras

Reply to
mkaras

Regardless of the issue of utilising 100% of the IO pins, the onboard clock multiplexers do a lot of the heavy lifting for you. I would suggest multiplexing ordinary IO rather than the clocks.

On using 100% of IO - in a practical design where space (and cost) are at a premium, I will use a device that has *what I need* and no more. Now I know that means it's tough to reconfigure and add signals, to say nothing of looking at the internal state by toggling lines appropriately (although that can be done if you're sneaky enough about it), but in a shipping design I need to look at cost - and IO pins (because they enlarge the package) are a very high cost on an FPGA.

I have a design in development right now where I am at the limit of IO pins on an FPGA and I am not going to add a separate device (except perhaps a single SPI IO device - cheap enough, but there are other issues), nor move to a larger FPGA (because I have to move to a larger core to get more IO in this particular family).

Using 2 smaller devices may or may not be appropriate - if you need _lots_ of IO and a small amount of logic it might work, but there's still power to be run, interfaces to be set up etc., and then when adding the cost of configuration devices (and you have to put those down if the resources in the FPGA are required for a processor at boot time) it's easily possible to exceed the cost of a large FPGA with two small ones, to say nothing of footprints (config devices are in god-awfully large packages).

So it's not an easy question to answer, but there _are_ times it's perfectly reasonable to have used 100% of FPGA IO pins.

Cheers

PeteS

Reply to
PeteS

I have yet to have success in 20 years of programmable design using a programmable part to do much with clocks and not make my life heck! The only solution I found that always works as I expect is to externally generate a clock, feed that into the FPGA, use a DCM (or PLL) to lock onto the clock if they run fast enough and run everything in the FPGA off that clock!

As for 500MHz - wow. I am just starting a 250 MHz design and I was worried.

Trevor

Reply to
Trevor Coolidge

My toughest challenges in programmable logic (and I've been doing it a long time too) have been going across clock domains where the dataflow is bidirectional, and things are quite fast.

FPGAs will add some jitter and it's difficult to know the exact amount (there's a very recent thread about this) and it depends on the loading of the clocks amongst other things. I try to separate functional blocks and clock the minimum number of FFs with any one clock, but I still get the occasional problem.

Cheers

PeteS

Reply to
PeteS

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.