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

Elmo Fuchs

Elmo Fuchs wrote:
> 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

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

mkaras

mkaras wrote:
> Elmo Fuchs wrote:
>
>>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
>
>
> 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
>

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

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




>
> 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

Trevor Coolidge

Trevor Coolidge wrote:
> 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
>
>
>
>
>> 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
>
>

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

PeteS