Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

configuring multiple fpga's with multiple bitstreams via JTAG connection.

Hello People,

I have successfully developped a special board with six fpga's (EP3C25) each fpga has its own EPCS16 configuration memory and they are programmed seperately on their own JTAG sockets.

but i have another project and i want to modify the board so that it will have the opportunity to change the bitstream and run another (and if possible more) projects with the same hardware.

My plan is,

a MCU will communicate with PC and according to the recieved command, choose which bitstream will be configured to the chained fpga's. MCU will have one big serial flash memory which will store totally 6 bitstreams for current 2 projects and future 4 projects. MCU will be able to update these bitstreams if needed. when a command is recieved to configure fpga's with 1st bitstream, MCU will do this. (also for other bitstreams)

single configuration bitstream will be configured on the JTAG chained fpga's. on the handbook, configuration by MCU is mentioned but there is not a jtag chain (multiple devices) example.

i am at the begining, and i need advises, has anyone made such a project?

has anyone share documentation about this?

what will be the specs of the MCU? for example, can i use 16 MHz, 8 bits Atmega2561 for this purpose? or more special MCU is required?

any serial memory chip (for 6 bitstreams) advises?

Thanks very much,

Regards..

8 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    You should consider, that selecting individual devices in the JTAG chain for configuration involves some overhead. In my opinion, the configuration scheme figure 9–28. jtag configuration of a single device using a microprocessor won't be well suited for this method, although it can be basically extended to a JTAG chain. I suggest to provide a JTAG chain for test and debugging purposes and use a PS or FPP configuration scheme that allows individual access to each FPGA, e.g. by using separate command and status and common DATA and DCLK lines.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    You should consider, that selecting individual devices in the JTAG chain for configuration involves some overhead. In my opinion, the configuration scheme figure 9–28. jtag configuration of a single device using a microprocessor won't be well suited for this method, although it can be basically extended to a JTAG chain. I suggest to provide a JTAG chain for test and debugging purposes and use a PS or FPP configuration scheme that allows individual access to each FPGA, e.g. by using separate command and status and common DATA and DCLK lines.

    --- Quote End ---

    thanks FvM, you're a real altera guru.

    by saying "not well suited" do you mean that this won't work properly?

    by saying " it can be basically extended to a JTAG chain", do you mean that i can extend it as the figure on 9-26 ?? is this enough?

    i told that this board will communicate with PC but this will be on the developer phase. later this board will be a part of a bigger standalone device and i will need to update bitstreams inside the big memory. also i will add aes encrypted communications between the main board of the standalone device and this board against chinese copies. main board will tell this board's MCU which bitstream will be configured on the fpgas.

    i don't need to individual access to fpgas because all fpgas will be configured with the same bitstream.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hi,

    Using JTAG to configure devices is possible. However, Altera do not make it that easy. The only option you really have is to port the Jam Player software to your microcontroller and then use that for configuration of the devices via JTAG.

    If you can tolerate using an x86 Linux board as the master in your system, you could consider running the JTAG server code on your x86 board, and then communicate with that board from Quartus on a server machine.

    In my designs, I use Fast Passive Parallel or Fast Passive Serial to program FPGAs. I also have JTAG chain programming, since MAX II devices can only be programmed this way. The Jam Player runs on an x86 host and can program devices over the PCI bus.

    For example documentation, see this board design;

    http://www.ovro.caltech.edu/~dwh/carma_board/ (http://www.ovro.caltech.edu/%7edwh/carma_board/)

    Schematic with a block diagram showing the JTAG chain:

    http://www.ovro.caltech.edu/~dwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf)

    Custom FPGA configuration controller:

    http://www.ovro.caltech.edu/~dwh/carma_board/fpga_configuration.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/fpga_configuration.pdf)

    Note that in this design the FPGAs can be powered off. This means that the JTAG chain can be broken. A power control CPLD in the design is used to create a short or long JTAG chain by including the FPGAs if they are powered, or excluding them if they are not.

    Cheers,

    Dave
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    If you want to use identical configuration bitstreams for all FPGAs, it's another strong reason not to configure them in a JTAG chain, because it requires the configuration to be performed sequential. PS or PP can be basically write to all devices in parallel, if the hardware is prepared for.

    As Dave explained, the main disadvantage of JTAG configuaration is the incomplete support by Altera. If you want to implement standalone configuration in a uC, you have to figure out a lot of details yourself. I also didn't exactly understand, why you're preferring JTAG over PP or PS.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Thanks brothers, i am an "Altera Pupil" and have lots of things to learn from you.

    With your advises, i have focused on Passive Serial (PS) method.

    and i have some more questions;

    1- What part can be used for serial flash memory ic? EPCS again? or more economic parts available? (i will need to memorize 6 seperate bitstreams (for cycloneIII - 25K) inside).

    2- is the buffer really needed? i will have 6 or 8 fpgas on the chain. if needed, which parts can you advise me?

    3- i will need to update the bitstreams in the memory ic. but the ic's data output is connected directly to the fpgas and no connection exists to the mcu. can i simply put a resistor on the existing line and connect the mcu directly before the resistor on the line? or how?

    Regards...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    If you intend to use serial flash, either Altera EPCS or compatible industry standard types, AS configuration scheme would be the most simple option. It could also use the Remote System Upgrade IP to select between configurations and won't necessarily need a µP for configuration control.

    PS is often used with parallel flash and serial data stream generated in the configuration controller, either MAX II (with PFL IP) or a µP.

    Buffers will be needed depending on the number of FPGAs and intended DCLK speed. Also the trace length plays a role. Standard 3.3V logic families, e.g. LVC can work.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    If you intend to use serial flash, either Altera EPCS or compatible industry standard types, AS configuration scheme would be the most simple option. It could also use the Remote System Upgrade IP to select between configurations and won't necessarily need a µP for configuration control.

    PS is often used with parallel flash and serial data stream generated in the configuration controller, either MAX II (with PFL IP) or a µP.

    Buffers will be needed depending on the number of FPGAs and intended DCLK speed. Also the trace length plays a role. Standard 3.3V logic families, e.g. LVC can work.

    --- Quote End ---

    Hello FvM,

    How many buffers should be used here? on the handbook there is only two Cyclone III devices and there is a buffer between the devices. But should we put additional buffers if there are more than two devices?

    i mean, one buffer after each device?

    Regards..
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    How many buffers should be used here? on the handbook there is only two Cyclone III devices and there is a buffer between the devices. But should we put additional buffers if there are more than two devices?

    i mean, one buffer after each device?

    --- Quote End ---

    Generally for clocks you want point-to-point routes on a PCB. Most buffers can drive a couple of source-terminated loads, so one buffer can be used to generate a couple of TCK and TMS fanouts. Take a look at the CARMA board design that I posted links to, look in the schematic:

    http://www.ovro.caltech.edu/~dwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf (http://www.ovro.caltech.edu/%7edwh/carma_board/gda06rb004_carma_v0.87_dec03.pdf)

    Page 7 has the JTAG high-level diagram. p44 has the Altera JTAG buffers. Note how the buffers have series terminations on their output - this is so that one buffer can drive multiple TCK and TMS traces. p77 shows some more buffering with dual-source terminations. p78 shows the inter-FPGA JTAG TDI/TDO chains. Since the I/O levels are 2.5V, the FPGAs can be connected directly. If the FPGA TDO driver was being powered from an I/O bank voltage of 1.8V, then a 1.8V-to-2.5V (or 3.3V) level translation buffer would be required when buffering between FPGAs. I have a buffer on the CEO# signal so that a red LED is turned off once the FPGAs are configured. This is nice for debugging.

    Cheers,

    Dave