On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote:> tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > just make MCU SPI slave ? > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > you can usually setup a DMA to do most of the workEmulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA?> > It just seems so lame to have the many modes in the chip and then to toss them away for one or two I/Os which can be reclaimed after booting or even before if not used in the mode selected. > > > > and why is the same pins not used for slave and master? (and serial)Serial is like the Xilinx config mode where one data line in is then daisy chained to one data line out. I believe the clock, etc. are shared. The master and slave are separated so they can be used together. Master to the flash prom and slave from an MCU. That allows the MCU to program the flash through the FPGA according to the config manual you linked to. I'm guessing you haven't actually read it much. What the config manual doesn't tell you is what config modes are available in what packages and chips. They leave that for you to figure out on your own by analyzing the pin out data. All in all, I can't give the documentation more than a 3 out of 5. They have lots of it, but finding it is a chore with it only being accessed through a search feature on the web page. Then much of it has errors of various degrees and much of it is written is poor English so that at times I can't figure out what they are trying to say. I would dig out some quotes, but I've been digging around the Medicare web site dealing with a whole 'nother level of frustration. JTAG is always there. I'm hoping I can find some inexpensive JTAG programmers or that I can figure out how to make the FTDI chip work with the Gowin tools. I can put an FTDI chip on the board for $5 and be done with it for the prototypes. I'm just not 100% certain it will work, but that's what they use on some of the Gowin boards and the Trenz board. I believe the Sipeed board uses a Chinese chip. I've ordered a couple. I wonder if I'll be able to program them. Didn't think of that, but it must work. People have reviewed the boards. I like design work, but sometimes the sheer number of things that can possibly go wrong is a bit overwhelming. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
Gowin FPGA Oddities
Started by ●September 15, 2020
Reply by ●September 15, 20202020-09-15
Reply by ●September 17, 20202020-09-17
onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C:> On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote: > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > > > > you can usually setup a DMA to do most of the work > > Emulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA? >usually the fpga just sends a 0x03 or 0x0b read command and a 24 bit address and then expect data from that address forward as it keeps on clocking you can usually ignore the received data and just send the config data with dummy bytes to account for the extra 8+24 clocks don't now about gowin but xilinx will also ignore data until it sees the bitpattern of the bitfile preamble
Reply by ●September 17, 20202020-09-17
On Thursday, September 17, 2020 at 12:22:51 PM UTC-4, lasselangwad...@gmail.com wrote:> onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C: > > On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote: > > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > > > > > > > you can usually setup a DMA to do most of the work > > > > Emulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA? > > > > usually the fpga just sends a 0x03 or 0x0b read command and a 24 bit address > and then expect data from that address forward as it keeps on clocking > > you can usually ignore the received data and just send the config data with dummy bytes to account for the extra 8+24 clocks > > don't now about gowin but xilinx will also ignore data until it sees the bitpattern of the bitfile preambleOk, that's an interesting idea. But still, this design won't use it other than in development maybe. The FPGA has to be paranoid and not trust the software so it can be independently validated. In the end application programming the FPGA will require jumpers or an outside cable or something to assure the software can't corrupt the FPGA. -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
Reply by ●September 17, 20202020-09-17
torsdag den 17. september 2020 kl. 19.32.50 UTC+2 skrev Rick C:> On Thursday, September 17, 2020 at 12:22:51 PM UTC-4, lasselangwad...@gmail.com wrote: > > onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C: > > > On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > > > > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > > > > > > > > > > you can usually setup a DMA to do most of the work > > > > > > Emulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA? > > > > > > > usually the fpga just sends a 0x03 or 0x0b read command and a 24 bit address > > and then expect data from that address forward as it keeps on clocking > > > > you can usually ignore the received data and just send the config data with dummy bytes to account for the extra 8+24 clocks > > > > don't now about gowin but xilinx will also ignore data until it sees the bitpattern of the bitfile preamble > > Ok, that's an interesting idea. But still, this design won't use it other than in development maybe. The FPGA has to be paranoid and not trust the software so it can be independently validated. In the end application programming the FPGA will require jumpers or an outside cable or something to assure the software can't corrupt the FPGA. >the bit file has crc too, atleast for xilinx so I'd assume everyone does since a random bitfile would be bad news. but anyway, if the fpga need to be programmed from the cpu the cpu needs control of the pin initiating configuration, if the fpga is critical that is probably a bad idea
Reply by ●September 17, 20202020-09-17
On Thursday, September 17, 2020 at 2:37:51 PM UTC-4, lasselangwad...@gmail.com wrote:> torsdag den 17. september 2020 kl. 19.32.50 UTC+2 skrev Rick C: > > On Thursday, September 17, 2020 at 12:22:51 PM UTC-4, lasselangwad...@gmail.com wrote: > > > onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C: > > > > On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > > > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > > > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > > > > > > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > > > > > > > > > > > > > you can usually setup a DMA to do most of the work > > > > > > > > Emulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA? > > > > > > > > > > usually the fpga just sends a 0x03 or 0x0b read command and a 24 bit address > > > and then expect data from that address forward as it keeps on clocking > > > > > > you can usually ignore the received data and just send the config data with dummy bytes to account for the extra 8+24 clocks > > > > > > don't now about gowin but xilinx will also ignore data until it sees the bitpattern of the bitfile preamble > > > > Ok, that's an interesting idea. But still, this design won't use it other than in development maybe. The FPGA has to be paranoid and not trust the software so it can be independently validated. In the end application programming the FPGA will require jumpers or an outside cable or something to assure the software can't corrupt the FPGA. > > > > the bit file has crc too, atleast for xilinx so I'd assume everyone does > since a random bitfile would be bad news. > > but anyway, if the fpga need to be programmed from the cpu the cpu needs > control of the pin initiating configuration, if the fpga is critical that > is probably a bad ideaThe programming is only during development. So a jumper would be used to isolate the FPGA during production. Presently my thinking is to include an FTDI chip to allow programming with a simple USB port during development. Not installed for product and using a cabled programmer. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
Reply by ●September 18, 20202020-09-18
On 16/09/2020 02:54, Rick C wrote:> On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, > lasselangwad...@gmail.com wrote: >> tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: >>> On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, >>> lasselangwad...@gmail.com wrote: >>>> tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick >>>> C: >>>>> Gowin seems to have some nice configuration modes in their >>>>> parts. Of course they have an auto boot from internal flash >>>>> and JTAG can be used to program either the RAM or the Flash. >>>>> They also have master and slave SPI modes, a serial mode that >>>>> daisy chains multiple FPGAs and a parallel bus mode along >>>>> with a mode to try reading external flash and fall back to >>>>> internal auto boot. But... they don't always make all of the >>>>> mode control pins available and/or the pins needed for the >>>>> various interfaces. >>>>> >>>>> In the QN88 package they leave out Mode2 so only the auto >>>>> boot and the two SPI modes are selectable. Then they leave >>>>> out the slave serial input pin so only auto boot, master SPI >>>>> and JTAG are left. If you want to configure the part from an >>>>> MCU you are stuck unless you want to emulate a JTAG driver! >>>>> They also don't make any of this clear from the >>>>> documentation. You have to read the pin list and figure out >>>>> that various signals are missing. Each package and even each >>>>> part are different. >>>>> >>>>> It is a chore figuring this stuff out. Many aspects of these >>>>> devices are inconsistent. >>>>> >>>> >>>> just make MCU SPI slave ? >>>> >>>> JTAG shouldn't be too terrible to do, >>>> https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 >>> >>> >>>>How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before.>>> >> >> you can usually setup a DMA to do most of the work > > Emulating a serial prom requires implementing a protocol I believe. > Is that possible with the timing constraints? Or is there a way to > make the FPGA wait while the MCU reads the command and sets up the > DMA? >This depends on what is sent on the SPI bus. If the FPGA uses a very simple command set - basically, send a single "read" command at address 0 then read in the N bytes needed for setup - then DMA should be simple and easy to arrange. If it is a complicated arrangement where it reads bits from different places, or perhaps does slave setup such as changing address sizes or dummy bytes when reading, then you are probably best handling it directly in an interrupt routine. In that case, you'll want a fast microcontroller - with SPI there is no option for the slave to make the master wait.> > JTAG is always there. I'm hoping I can find some inexpensive JTAG > programmers or that I can figure out how to make the FTDI chip work > with the Gowin tools. I can put an FTDI chip on the board for $5 and > be done with it for the prototypes. I'm just not 100% certain it > will work, but that's what they use on some of the Gowin boards and > the Trenz board. I believe the Sipeed board uses a Chinese chip. > I've ordered a couple. I wonder if I'll be able to program them. > Didn't think of that, but it must work. People have reviewed the > boards.FTDI chips are at the heart of most cheap JTAG programmers and debuggers. But while JTAG is standardised at the low level, the extensions used by microcontrollers, FPGA's, etc., for debugging and programming are not standardised. If you are looking for software here, start with OpenOCD. While it is primarily targeting ARM microcontrollers, it also handles a range of other microcontrollers and (I think) some programmable logic.> > I like design work, but sometimes the sheer number of things that can > possibly go wrong is a bit overwhelming. >
Reply by ●September 18, 20202020-09-18
fredag den 18. september 2020 kl. 00.20.45 UTC+2 skrev Rick C:> On Thursday, September 17, 2020 at 2:37:51 PM UTC-4, lasselangwad...@gmail.com wrote: > > torsdag den 17. september 2020 kl. 19.32.50 UTC+2 skrev Rick C: > > > On Thursday, September 17, 2020 at 12:22:51 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C: > > > > > On Tuesday, September 15, 2020 at 5:35:43 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C: > > > > > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, lasselangwad...@gmail.com wrote: > > > > > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C: > > > > > > > > > Gowin seems to have some nice configuration modes in their parts. Of course they have an auto boot from internal flash and JTAG can be used to program either the RAM or the Flash. They also have master and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fall back to internal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces. > > > > > > > > > > > > > > > > > > In the QN88 package they leave out Mode2 so only the auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want to emulate a JTAG driver! They also don't make any of this clear from the documentation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different. > > > > > > > > > > > > > > > > > > It is a chore figuring this stuff out. Many aspects of these devices are inconsistent. > > > > > > > > > > > > > > > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eevblog.com/forum/projects/(poll)-fpga-board-form-factor/?action=dlattach;attach=928670 > > > > > > > > > > > > > > How does that work? The MCU can pump out addressed data at Mbps? That's a tough thing to do in general and if it has anything else to do - even tougher. I guess when programming the FPGA there isn't anything else for the MCU to do, so it just has to retrieve the appropriate data quickly enough to get it into the SPI hardware to ship out. I don't know how much time that gives. I haven't seen the interface spec before. > > > > > > > > > > > > > > > > > > > you can usually setup a DMA to do most of the work > > > > > > > > > > Emulating a serial prom requires implementing a protocol I believe. Is that possible with the timing constraints? Or is there a way to make the FPGA wait while the MCU reads the command and sets up the DMA? > > > > > > > > > > > > > usually the fpga just sends a 0x03 or 0x0b read command and a 24 bit address > > > > and then expect data from that address forward as it keeps on clocking > > > > > > > > you can usually ignore the received data and just send the config data with dummy bytes to account for the extra 8+24 clocks > > > > > > > > don't now about gowin but xilinx will also ignore data until it sees the bitpattern of the bitfile preamble > > > > > > Ok, that's an interesting idea. But still, this design won't use it other than in development maybe. The FPGA has to be paranoid and not trust the software so it can be independently validated. In the end application programming the FPGA will require jumpers or an outside cable or something to assure the software can't corrupt the FPGA. > > > > > > > the bit file has crc too, atleast for xilinx so I'd assume everyone does > > since a random bitfile would be bad news. > > > > but anyway, if the fpga need to be programmed from the cpu the cpu needs > > control of the pin initiating configuration, if the fpga is critical that > > is probably a bad idea > > The programming is only during development. So a jumper would be used to isolate the FPGA during production. > > Presently my thinking is to include an FTDI chip to allow programming with a simple USB port during development. Not installed for product and using a cabled programmer. >why not use the standard ftdi cable, then you'll only need a header and it'll also give pads for pogo pins in production https://github.com/trabucayre/openFPGALoader
Reply by ●September 18, 20202020-09-18
On Fri, 18 Sep 2020 09:49:05 +0200 David Brown <david.brown@hesbynett.no> wrote:> How does that work? The MCU can pump out addressed data at Mbps? > That's a tough thing to do in general and if it has anything else to do > - even tougher. I guess when programming the FPGA there isn't anything > else for the MCU to do, so it just has to retrieve the appropriate data > quickly enough to get it into the SPI hardware to ship out. I don't > know how much time that gives. I haven't seen the interface spec before.The iCE40, and probably other FPGAs, use SPI slave mode for cable based programming, so the PC, micro, or other bitstream source device has full control of the transfer rate. This is very good for development, as programming the FPGA RAM takes just a couple of second, rather than the ~30s to flash the regular external SPI bitstream device. Jan Coombs
Reply by ●September 18, 20202020-09-18
On 18/09/2020 13:43, Jan Coombs wrote:> On Fri, 18 Sep 2020 09:49:05 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> How does that work? The MCU can pump out addressed data at Mbps? >> That's a tough thing to do in general and if it has anything else to do >> - even tougher. I guess when programming the FPGA there isn't anything >> else for the MCU to do, so it just has to retrieve the appropriate data >> quickly enough to get it into the SPI hardware to ship out. I don't >> know how much time that gives. I haven't seen the interface spec before. > > The iCE40, and probably other FPGAs, use SPI slave mode for cable based > programming, so the PC, micro, or other bitstream source device has full > control of the transfer rate. This is very good for development, as > programming the FPGA RAM takes just a couple of second, rather than the > ~30s to flash the regular external SPI bitstream device. >Yes, that mode is more useful for when you have a PC or microcontroller providing the image. But as I understand it, on this particular FPGA in this particular package, that mode is not available - only the FPGA as master is available. One other method that might be possible for the OP is to have the microcontroller program an external SPI device, then let the FPGA boot from that. It shouldn't be too hard to do, even with the pin sharing, unless the pin voltages are different on the microcontroller and the FPGA.
Reply by ●September 18, 20202020-09-18
On 18/09/2020 14:27, David Brown wrote:> On 18/09/2020 13:43, Jan Coombs wrote: >> On Fri, 18 Sep 2020 09:49:05 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >> > > One other method that might be possible for the OP is to have the > microcontroller program an external SPI device, then let the FPGA boot > from that. It shouldn't be too hard to do, even with the pin sharing, > unless the pin voltages are different on the microcontroller and the FPGA. > >Yes, that'll work - I suggested it in the second post in this thread ;-) I've done it with Lattice (ECP3) parts. MK
