FPGA config sizes

I don't know about these Xilinx parts, but I read once that someone verifie d that two different sized Altera parts (Intel now) were the same die. See ms the silicon costs are not large enough to be dominant and the savings on the mask costs and the cost of testing is such that they can use a larger part, but only tested to a subset that provides the functionality of a smal ler part saves them enough money to be the more profitable way to go. The Xilinx Artix 35T and 50T are possibly the same part.

ied that two different sized Altera parts (Intel now) were the same die. S eems the silicon costs are not large enough to be dominant and the savings on the mask costs and the cost of testing is such that they can use a large r part, but only tested to a subset that provides the functionality of a sm aller part saves them enough money to be the more profitable way to go. Th e Xilinx Artix 35T and 50T are possibly the same part.

reconfiguration-

Our experience on Zynqs with nand Flash was that compression made it faster, because the nand Flash (as opposed to the decompression or the configuration interface) was actually limiting the speed.

Allan

My PHB answer would be 32 Mbit.

However, "mid-range" FPGA is a very broad definition. These days I would call mid-range something like the Spartan 7 family, but probably someone could argue that it is already low-range. So you could choose 32 Mbit (which is the maximum bitstream size required for the Spartan-7 and for a mid-range Artix 7) or go a little further to accomodate also the mid-range Kintex-7. See table 1-1:

I think that would work for us. The uP has a boot loader that finds the correct code image to copy into the ARM flash, the runtime app. It only does that once if there is a newer, upgraded code image available, newer than the factory-ship image. The app then locates the FPGA image that it wants to run. Users can upgrade in the field.

The uP can bang \PROGB to reset the FPGA. Then we do your thing, read in the FPGA config from the external flash as fast as we can, but ignore it. Later we check a register or two to make sure it worked, and maybe verify the FPGA code version. Only needs one SPI interface and hardly any code.

I'll try to sell that to the boys and girls.

I think our ARM can do 100 MHz SPI. I have done 50. My 17 mbit Artix7 would configure in way under a second, even uncompressed.

My people are bugging me to use a quad SPI flash, which I prefer to not do. This pretty much shoots down that idea.

niptechnology.com:

dsniptechnology.com:

and

e and

GA

lly

ine

tion

n a

ion-

ut

ot

M.

ta

ga

ata

I think the FPGA is also limited to ~100MHz

I think you can access most if not all quad SPI flash in single bit mode so it could still work.

you can also do the configuration in parallel with 8, 16 or 32 bit per cclk with selectmap

the pins could be reused for a faster interface to the MCU after configurat ion

Altera EP3C5F256 and EP3C10F256 seem to be the same part. Either will configure and work with a bit stream compiled for the other.