FPGA config sizes

[Lasse Langwadt Christense]

lørdag den 9. november 2019 kl. 18.29.22 UTC+1 skrev jla...@highlandsniptechnology.com:

On Sat, 09 Nov 2019 01:27:44 -0600, Allan Herriman
allanherriman@hotmail.com> wrote:

On Fri, 08 Nov 2019 12:20:44 -0800, John Larkin wrote:

On Fri, 8 Nov 2019 11:43:08 -0800 (PST), edward.ming.lee@gmail.com
wrote:

On Friday, November 8, 2019 at 11:09:04 AM UTC-8, John Larkin wrote:
We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?


Page 21:

https://www.xilinx.com/support/documentation/user_guides/ug570-
ultrascale-configuration.pdf

I was just wondering what sort of config file sizes people were really
seeing. Maybe compressed, too.

Looks like a 1 or 2 Gbit serial flash is cheap nowadays. I can imagine
storing maybe four configs in the flash chip.


The built-in bitstream compression merely reuses indentical configuration
frames. This gives good results on an empty FPGA, but poor results on a
moderately utilised one.

We use gzip -9 here. From this thread on the Xilinx forum,
https://forums.xilinx.com/t5/FPGA-Configuration/Complete-reconfiguration-
with-GZip-ed-bitstream/m-p/667837#M4437
I can see that this gives a compression ranging from 28:1 to 2.8:1, but
usually about 3.8 : 1 for a typical FPGA.
Please note that ungzipping is only possible in software. You will not
be able to use that method if configuring an FPGA directly from a PROM.

Regards,
Allan

I did a little compression thing, file compressor in PowerBasic and
unpacker in assembly, based on finding runs of 1s or 0s. Typical
compression was 2:1 or better, and the decoder was small and very
fast. It configured most FPGAs faster than the un-compressed version,
because the 1-or-0 unpack bursts were the tightest possible loops.

I wouldn't use that again, because an ARM with hardware SPI or QSPI
interfaces, from serial flash and to the FPGA config pins, would
probably be faster.

if you don't do you own compression you don't even need to handle the data

just put the DIN,CCLK on the fpga in parallel with the dout and sclk
on the flash

Give the flash a start address and read command, pulse program on the fpga
and run the spi clk as fast as the flash/fpga an take it, ignoring the data

 

[Lasse Langwadt Christense]

søndag den 10. november 2019 kl. 03.56.01 UTC+1 skrev Rick C:

On Saturday, November 9, 2019 at 4:49:56 AM UTC-5, Michael Kellett wrote:
On 08/11/2019 19:08, John Larkin wrote:


We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.

LFE5-45 - 8.86Mb


From Xilinx UG470
Xilinx Artix 35T and 50T need the same 17.536 Mb

I don't know about these Xilinx parts, but I read once that someone verified that two different sized Altera parts (Intel now) were the same die. Seems 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 smaller part saves them enough money to be the more profitable way to go. The Xilinx Artix 35T and 50T are possibly the same part.

https://www.eevblog.com/forum/fpga/are-xilinx-xc7a35t-actually-the-same-die-as-something-else-or/msg2543253/#msg2543253

 

[Rick C]

On Saturday, November 9, 2019 at 4:49:56 AM UTC-5, Michael Kellett wrote:

On 08/11/2019 19:08, John Larkin wrote:


We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.

LFE5-45 - 8.86Mb


From Xilinx UG470
Xilinx Artix 35T and 50T need the same 17.536 Mb

I don't know about these Xilinx parts, but I read once that someone verified that two different sized Altera parts (Intel now) were the same die. Seems 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 smaller part saves them enough money to be the more profitable way to go. The Xilinx Artix 35T and 50T are possibly the same part.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

 

[Allan Herriman]

On Sat, 09 Nov 2019 09:29:03 -0800, jlarkin wrote:

On Sat, 09 Nov 2019 01:27:44 -0600, Allan Herriman
allanherriman@hotmail.com> wrote:

On Fri, 08 Nov 2019 12:20:44 -0800, John Larkin wrote:

On Fri, 8 Nov 2019 11:43:08 -0800 (PST), edward.ming.lee@gmail.com
wrote:

On Friday, November 8, 2019 at 11:09:04 AM UTC-8, John Larkin wrote:
We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code
and one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?


Page 21:

https://www.xilinx.com/support/documentation/user_guides/ug570-
ultrascale-configuration.pdf

I was just wondering what sort of config file sizes people were really
seeing. Maybe compressed, too.

Looks like a 1 or 2 Gbit serial flash is cheap nowadays. I can imagine
storing maybe four configs in the flash chip.


The built-in bitstream compression merely reuses indentical
configuration frames. This gives good results on an empty FPGA, but
poor results on a moderately utilised one.

We use gzip -9 here. From this thread on the Xilinx forum,
https://forums.xilinx.com/t5/FPGA-Configuration/Complete-
reconfiguration-
with-GZip-ed-bitstream/m-p/667837#M4437 I can see that this gives a
compression ranging from 28:1 to 2.8:1, but usually about 3.8 : 1 for a
typical FPGA.
Please note that ungzipping is only possible in software. You will not
be able to use that method if configuring an FPGA directly from a PROM.

Regards,
Allan

I did a little compression thing, file compressor in PowerBasic and
unpacker in assembly, based on finding runs of 1s or 0s. Typical
compression was 2:1 or better, and the decoder was small and very fast.
It configured most FPGAs faster than the un-compressed version,
because the 1-or-0 unpack bursts were the tightest possible loops.

I wouldn't use that again, because an ARM with hardware SPI or QSPI
interfaces, from serial flash and to the FPGA config pins, would
probably be faster.

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

 

[dalai lamah]

Un bel giorno John Larkin digitň:

We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

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:

https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf

--
Fletto i muscoli e sono nel vuoto.

 

On Sat, 9 Nov 2019 12:27:36 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

lřrdag den 9. november 2019 kl. 18.29.22 UTC+1 skrev jla...@highlandsniptechnology.com:
On Sat, 09 Nov 2019 01:27:44 -0600, Allan Herriman
allanherriman@hotmail.com> wrote:

On Fri, 08 Nov 2019 12:20:44 -0800, John Larkin wrote:

On Fri, 8 Nov 2019 11:43:08 -0800 (PST), edward.ming.lee@gmail.com
wrote:

On Friday, November 8, 2019 at 11:09:04 AM UTC-8, John Larkin wrote:
We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?


Page 21:

https://www.xilinx.com/support/documentation/user_guides/ug570-
ultrascale-configuration.pdf

I was just wondering what sort of config file sizes people were really
seeing. Maybe compressed, too.

Looks like a 1 or 2 Gbit serial flash is cheap nowadays. I can imagine
storing maybe four configs in the flash chip.


The built-in bitstream compression merely reuses indentical configuration
frames. This gives good results on an empty FPGA, but poor results on a
moderately utilised one.

We use gzip -9 here. From this thread on the Xilinx forum,
https://forums.xilinx.com/t5/FPGA-Configuration/Complete-reconfiguration-
with-GZip-ed-bitstream/m-p/667837#M4437
I can see that this gives a compression ranging from 28:1 to 2.8:1, but
usually about 3.8 : 1 for a typical FPGA.
Please note that ungzipping is only possible in software. You will not
be able to use that method if configuring an FPGA directly from a PROM.

Regards,
Allan

I did a little compression thing, file compressor in PowerBasic and
unpacker in assembly, based on finding runs of 1s or 0s. Typical
compression was 2:1 or better, and the decoder was small and very
fast. It configured most FPGAs faster than the un-compressed version,
because the 1-or-0 unpack bursts were the tightest possible loops.

I wouldn't use that again, because an ARM with hardware SPI or QSPI
interfaces, from serial flash and to the FPGA config pins, would
probably be faster.


if you don't do you own compression you don't even need to handle the data

just put the DIN,CCLK on the fpga in parallel with the dout and sclk
on the flash

Give the flash a start address and read command, pulse program on the fpga
and run the spi clk as fast as the flash/fpga an take it, ignoring the data

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.



--

John Larkin Highland Technology, Inc

lunatic fringe electronics

 

[Lasse Langwadt Christense]

søndag den 10. november 2019 kl. 17.01.29 UTC+1 skrev jla...@highlandsniptechnology.com:

On Sat, 9 Nov 2019 12:27:36 -0800 (PST), Lasse Langwadt Christensen
langwadt@fonz.dk> wrote:

lørdag den 9. november 2019 kl. 18.29.22 UTC+1 skrev jla...@highlandsniptechnology.com:
On Sat, 09 Nov 2019 01:27:44 -0600, Allan Herriman
allanherriman@hotmail.com> wrote:

On Fri, 08 Nov 2019 12:20:44 -0800, John Larkin wrote:

On Fri, 8 Nov 2019 11:43:08 -0800 (PST), edward.ming.lee@gmail.com
wrote:

On Friday, November 8, 2019 at 11:09:04 AM UTC-8, John Larkin wrote:
We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?


Page 21:

https://www.xilinx.com/support/documentation/user_guides/ug570-
ultrascale-configuration.pdf

I was just wondering what sort of config file sizes people were really
seeing. Maybe compressed, too.

Looks like a 1 or 2 Gbit serial flash is cheap nowadays. I can imagine
storing maybe four configs in the flash chip.


The built-in bitstream compression merely reuses indentical configuration
frames. This gives good results on an empty FPGA, but poor results on a
moderately utilised one.

We use gzip -9 here. From this thread on the Xilinx forum,
https://forums.xilinx.com/t5/FPGA-Configuration/Complete-reconfiguration-
with-GZip-ed-bitstream/m-p/667837#M4437
I can see that this gives a compression ranging from 28:1 to 2.8:1, but
usually about 3.8 : 1 for a typical FPGA.
Please note that ungzipping is only possible in software. You will not
be able to use that method if configuring an FPGA directly from a PROM.

Regards,
Allan

I did a little compression thing, file compressor in PowerBasic and
unpacker in assembly, based on finding runs of 1s or 0s. Typical
compression was 2:1 or better, and the decoder was small and very
fast. It configured most FPGAs faster than the un-compressed version,
because the 1-or-0 unpack bursts were the tightest possible loops.

I wouldn't use that again, because an ARM with hardware SPI or QSPI
interfaces, from serial flash and to the FPGA config pins, would
probably be faster.


if you don't do you own compression you don't even need to handle the data

just put the DIN,CCLK on the fpga in parallel with the dout and sclk
on the flash

Give the flash a start address and read command, pulse program on the fpga
and run the spi clk as fast as the flash/fpga an take it, ignoring the data

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.

I think the FPGA is also limited to ~100MHz

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

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 configuration

 

On Sat, 9 Nov 2019 19:14:24 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:

sřndag den 10. november 2019 kl. 03.56.01 UTC+1 skrev Rick C:
On Saturday, November 9, 2019 at 4:49:56 AM UTC-5, Michael Kellett wrote:
On 08/11/2019 19:08, John Larkin wrote:


We're planning a new universal boot loader for a family of ST
processors. The uP would host the loader in a bit of local flash and
read an outboard serial flash to get the specific application code and
one or more FPGA configurations.

So, how many config bits might there be for a modern mid-range FPGA
doing a moderately complex application?

I think we could enable compression too.

Please consider this a PHB type question. I don't do FPGA development
myself, past whiteboarding.

From Lattice ECP5 sysCONFIG Usage Guide FPGA-TN-02039.

LFE5-45 - 8.86Mb


From Xilinx UG470
Xilinx Artix 35T and 50T need the same 17.536 Mb

I don't know about these Xilinx parts, but I read once that someone verified that two different sized Altera parts (Intel now) were the same die. Seems 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 smaller part saves them enough money to be the more profitable way to go. The Xilinx Artix 35T and 50T are possibly the same part.


https://www.eevblog.com/forum/fpga/are-xilinx-xc7a35t-actually-the-same-die-as-something-else-or/msg2543253/#msg2543253

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



--

John Larkin Highland Technology, Inc

lunatic fringe electronics