Xilinx Virtex-4 Clock Multiplexer Inputs

Discussion in 'VHDL' started by Elmo Fuchs, Oct 27, 2006.

  1. Elmo Fuchs

    Elmo Fuchs Guest

    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, Oct 27, 2006
    #1
    1. Advertising

  2. Elmo Fuchs

    mkaras Guest

    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, Oct 27, 2006
    #2
    1. Advertising

  3. Elmo Fuchs

    PeteS Guest

    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, Oct 27, 2006
    #3
  4. 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, Nov 18, 2006
    #4
  5. Elmo Fuchs

    PeteS Guest

    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, Nov 18, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Oleg
    Replies:
    4
    Views:
    6,800
    Ray Andraka
    Apr 6, 2004
  2. Steven
    Replies:
    0
    Views:
    996
    Steven
    Sep 9, 2004
  3. Replies:
    1
    Views:
    1,448
    kunal
    Jul 11, 2007
  4. Replies:
    6
    Views:
    600
  5. udayjayachandran
    Replies:
    0
    Views:
    992
    udayjayachandran
    Jul 12, 2010
Loading...

Share This Page