Multi Device AS configuration scheme

1) The FPGA's internal configuration state machine relies on two of these signals being shorted between devices when multiple FPGAs are configured from the same configuration device.

2) Yes, you can monitor CONF_DONE separately.

3) CONF_DONE is an open-drain signal will require a pull-up resistor for it to work correctly. So, you'll need one pull-up resistor per CONF_DONE signal.

Regards,

Alex

Thanks for your reply..

Sir you have mentioned that FPGA's internal configuration state machine relies on two of these (nCONFIG, nSTATUS and CONF_DONE) signals.

Are they only nCNFIG and nSTATUS?

Yes, that's right. I'm suggesting CONF_DONE can be treated separately.

however, there is an important consideration which is going to contradict what I've already said, something that I was reminded of after a little further reading...

When the FPGA releases CONF_DONE it enters user mode - the mode in which it starts doing what you want it to. If your design makes use of any of the pins used for AS configuration your code is going to take over the control of them. They will start doing whatever you've designed them to do.

Assume you have two devices. The first boots and enters user mode while the second FPGA continues to boot. If the first device makes use of the AS configuration pins (it may wish to access the EPCS as part of its design) and it attempts to do so then the second device is not going to boot successfully.

By ensuring CONF_DONE is common across all the FPGAs booting from a single EPCS, you are guaranteeing none of them enters user mode until the last device has successfully booted. The last device in the chain will hold all CONF_DONE pins low preventing any of the FPGAs entering user mode until it has booted.

However, there is a further complication. Once a device enters user mode the DCLK pin is under user control. If the first device in the chain is responsible for generating DCLK during configuration then, once it has entered user mode, it is going to stop generating clock cycles - preventing the other devices from booting. Is the first device in the chain responsible for clocking the EPCS? I don't believe that is explicitly clear from the documentation, but I suspect it is.

See: serial configuration (epcs) devices datasheet (http://www.altera.com/literature/hb/cfg/cyc_c51014.pdf)

Figure 4 implies this is the case, but no description explicitly states this.

What might clinch this categorically is control of the nCS pin on the EPCS. This only comes from the 1st FPGA. Once it enters user mode is will not (necessarily) control this pin in a way that allows the other FPGAs to boot.

So, to go full circle - I recommend to do short the CONF_DONE (and nSTATUS & nCONFIG) pins across multiple devices when booting them all from a single EPCS - as per Figure 4 in the Serial Config Datasheet. If you really must have the FPGAs enter user mode independently of each other, boot each from their own EPCS...

Regards,

Alex

Refer to Figure 7-7 on page 7-16 of the cyclone v device handbook (https://www.altera.com/en_us/pdfs/literature/hb/cyclone-v/cv_5v2.pdf). Two (or more) devices boot from a single EPCS. If you want both FPGAs to boot with the same image simply put two copies of the same image into memory.

Cheers,

Alex

You can't boot two FPGAs in parallel in AS mode. Which FPGA's DCLK would you use as the source? The FPGAs are not going to be able to synchronise their configuration clocks such that this could work. Using the clock from one FPGA to clock data into the other FPGA is not going to result in the correct data/clock alignment for the second FPGA.

If you want to boot them in parallel you'd have to use a passive configuration mode (e.g. passive serial). However, you wouldn't be able to rely on Cyclone V's 'built in' remote upgrade facility. You'd have to support this in another way.

Cheers,

Alex

--- Quote Start ---

Which FPGA's DCLK would you use as the source?

--- Quote End ---

The first FPGA generate DCLK for ECPQ and second FPGA which is configured as PS device. What problem for DCLK of first FPGA? For all devises phase equally or not?

This link (page 1-60, Figure 1-55) https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ccgqfjae&url=http%3a%2f%2fcatalog.gaw.ru%2fproject%2fdownload.php%3fid%3d39779&ei=0tojvbr3esyvsggnl4dwaw&usg=afqjcnhfcya93r_res3gfmrzyt2ji3cxxq&sig2=6kidmjotjhnt73sfepwena&bvm=bv.89947451,d.bgg&cad=rjt is illustrated that situation, but for using the Arria 5.

Figure 1-55

http://www.alteraforum.com/forum/attachment.php?attachmentid=10478&stc=1

--- Quote Start ---

Which FPGA's DCLK would you use as the source?

--- Quote End ---

The first FPGA (in mode AS) will generate DCLK for EPCQ and the second FPGA (in mode PS). What broblem for the this DCLK generated by the first FPGA ? DCLK is one and the same for all devises in our scheme. Or in this case phase for our devises will be different into internal scheme of the system clock and data recovery each devises (fpga_1, fpga_2, epcq)?

This link on "Arria V Device Handbook Volume 4: Device Basics (November 2011)" https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ccgqfjae&url=http%3a%2f%2fcatalog.gaw.ru%2fproject%2fdownload.php%3fid%3d39779&ei=iwclvdtnnybnywpmxocoba&usg=afqjcnhfcya93r_res3gfmrzyt2ji3cxxq&sig2=utk2zlpub15amul6dc_yca&cad=rjt (https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=5&ved=0ccgqfjae&url=http%3a%2f%2fcatalog.gaw.ru%2fproject%2fdownload.php%3fid%3d39779&ei=iwclvdtnnybnywpmxocoba&usg=afqjcnhfcya93r_res3gfmrzyt2ji3cxxq&sig2=utk2zlpub15amul6dc_yca&cad=rjt) (page 1-61, figure 1-56) illustrate this situation, but for the fpga arria 5. Сan I use this scheme of configuration for the cyclone 5?

https://www.alteraforum.com/forum/attachment.php?attachmentid=10485

Sorry for the slow response....

I've never seen this stated as a supported method in any documentation for Cyclone V. However, fundamentally the configuration bitstream is the same for AS & PS and both are supported in Arria V & Cyclone V. So, if Arria V supports it I suspect Cyclone V will too.

Cheers,

Alex