questions: PS configuration of cyclone3 EP3C5F256

[Altera_Forum]

I'm working on my first design with an FPGA, and am just ready to send out files to have prototype PCBs made. I just realized I might not understand the details of how PS (passive serial) configuration works, and whether I have a large-enough flash-memory to contain the configuration data. So I'll explain what I was planning to do, then ask some questions. 

 I have a C8051F120 CPU (a fast 8051/8052 uP/uC variant) that will read configuration data from a 4 megabit flash memory chip, and twiddle the DCLK and DATA0 signals on the EP3C5F256 FPGA to configure it. The other configuration signals like nSTATUS and CONF_DONE are also routed to CPU i/o pins, and the CPU manually resets the FPGA with one of its i/o pins.  The cyclone3 documentation says quartus generates a 3,000,000 bit .rbf binary file for this FPGA, which then can be "compiled" into (much larger I presume) text encoded files like .hex and .ttf (and others?). The documentation also says the configuration data can be "compressed" or "uncompressed".  When I designed this PCB, I assumed the flash memory would only need to contain one set of FPGA configuration data, and that would be sufficient to perform all functionality.  Mostly this means "capture pixel data from a CCD as it arrives, perform simple lossless compression, put the compressed pixel data for each row of pixels into an ethernet packet, compute and appending the CRC32, then clock the bytes of the ethernet packet into a gigabit ethernet PHY".  In other words, this FPGA firmware already knows how to read and write ethernet packets via the gigabit ethernet PHY.  However, there is one other important functionality that I also assumed could be part of the totality of this FPGA firmware, and that is "upload new FPGA firmware" from the attached PC through this very same gigabit ethernet connection. Essentially, this process is simply to recognize that one of the commands it receives from the PC has nothing to do with the main functionality of operating a high-speed video/still camera, but simply to capture a long series of ethernet packets and pass them to the CPU, which can reprogram the flash memory chip that contains the FPGA configuration AKA firmware.  This may have been somewhat naive... or just plain stupid. I've done this sort of thing with CPUs many times, and it is easy as can be - because the CPU never, ever, ever writes over the "core code" at the bottom of its memory space, which knows how to upload new versions of "everything else" that it happy writes over the portion of its flash memory that contains all its memory space ABOVE that core code. In this way, the firmware upload code can NEVER be polluted or destroyed by power failure during the process or anything else (except the low/core pages of the flash memory chip failing).  But I guess the FPGA configuration bits cannot be "segmented" this way, right? What I mean is, I can't have [say] 1,000,000 bits of FPGA configuration file that contain what is necessary for the FPGA to operate the PHY and execute an "upload firmware" command, then upload [say] 2,000,000 bits of FPGA configuration file into the upper part of the flash-memory space... then simply program that whole mess into the FPGA chip.  In other words, I'm now guessing the entire FPGA must be configured at once, AND I can't simply merge a 1,000,000 bit configuration file with a 2,000,000 bit configuration file and have a viable working 3,000,000 bit configuration file to configure the FPGA with.  For a moment, this seemed like a HUGE deal. Then I realized this MAY not be a huge deal ---IF--- the flash memory can hold two complete sets binary configuration data. Since the flash memory holds 4,000,000 bits, and the EP3C5F256 FPGA only requires a 3,000,000 bit configuration file (at most, I presume), can I store the much smaller set of firmware needed to operate the PHY and upload configuration data but nothing else in (say) 1,000,000 bits of the flash memory... then upload new 3,000,000 bit configuration files into the other 3,000,000 bits of flash memory reserved for normal configuration?  The answer seems to come down to this. Can configuration files be very short if only a small percentage of the FPGA needs to do anything coherent? And if so, is there some kind of "that's all folks" code in the binary configuration file that can tell the FPGA "all done, that's all you need to configure"? Or is there some equivalent of a NOP code that can be fed in after the necessary configuration data to make everything else enter into some kind of benign, non-functioning state?  In other words, what if all you need your cyclone3 FPGA to do is these two things (in two totally separate configurations):  # 1: simulate a 2-input AND gate. # 2: simulate a 2-input OR gate.  Do you really need to have two 3,000,000 bit configuration files? Really?  Also, why does both the EP3C5 and EP3C10 require 3,000,000 bits of configuration when the EP3C10 contains many more LEs and LABs? I mean, this must mean that a substantial portion of the EP3C5 configuration file must contain nothing functional anyway, right?  The next question is this. If the EP3C5 absolutely positively MUST have a 3,000,000 bit binary configuration file... how much smaller will this file be if in compressed form (which appears to be compatible with PS (passive serial) configuration)? If a 3,000,000 bit configuration file because 2,000,000 bits or smaller, I can store two complete configuration files in the 4 megabit flash memory.  The above question comes in two flavors too. If a configuration file is making an FPGA do very little (like simulate/implement a 2-input AND gate), does that configuration file become much smaller in compressed form than a configuration file that needs every last LE and LAB and RAM-block in the FPGA? If so, perhaps I can assume the set of firmware to perform a firmware update will consume much less than the firmware to make the entire device function. Then perhaps 1,500,000 bits of flash memory is sufficient for the compressed firmware update configuration, and 2,500,000 bits of flash memory is sufficient for the compressed device-operation configuration. Make sense?  I cannot find anywhere that states how these tradeoffs work, or how much the compression reduces the size of flash memory required, or how the simplicity or complexity of the configuration impacts the compression efficiency, etc. Maybe I'm looking in the wrong places, but I can't find it.  Can anyone answer these questions? I'll appreciate it. I'm hoping I need not switch to a double-size flash memory. Worse yet, I hope I need not change the PCB design on the literal eve of sending them off for prototypes! :-o  Thanks in advance to anyone who can supply answers and tips.

[Altera_Forum]

Hi, 

I am not an expert in this area but just few comments. I am familiar with using a large flash with multiple images(factory image,production image...nios software images...etc).   First, and as far as I know ,the size of bitstream files is fixed per device irrespective of functionality size. The bitstream needs to define the status of every sram switch inside the fpga.  second, your options can be either compressed files or partial reconfiguration. You will need to find out the figures for compression sizes and how to? I am not sure if altera devies support partial reconfig , I doubt it.

[Altera_Forum]

Trying to further clarify some points: 

 - You have to write the complete configuration bitstream, as contained in the *.rbf file, otherwise the configuration will fail.  - Altera doesn't support partial reconfiguration for any FPGA family up to now  - A design with low LE count will considerably shrink in compressed mode (e.g. to 1/3 of original size). The compression algorithm is however designed for compact implementation in FPGA hardware and doesn't achieve results comparable to e.g. ZIP. To minimize flash memory footprint, you may want to apply an additional software compression/decompression in your application.