Forums

FPGA config sizes

Started by John Larkin November 8, 2019
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
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
s&oslash;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
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
Un bel giorno John Larkin digit&#2013265922;:

> 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&#2013266168;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
s&oslash;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&oslash;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&#2013266168;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