On Friday, September 18, 2020 at 7:43:07 AM UTC-4, 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.This device is a Gowin GW1N series product. They provide an $80 programming cable or use the FTDI chip in their board products as does Trenz. Gowin can't rely on any other mode for programming their devices because SPI slave mode is not supported on all devices. It seems insane, but they have five programming modes not counting JTAG and Auto Boot (from internal flash) but one some devices/packages offer only one alternative because they don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a single mode pin, Mode 0. In that case Slave SPI is the only other choice than Auto Boot. In other packages the only other choice is Master SPI or only CPU 8 bit parallel. Heck, in some packages the mode pin out changes between devices! Strange. So I am left with the choices of buying an $80 cable for everyone, or adding the FTDI chip to the board. I'll add the chip unless someone has a truly better idea. It seems to be the cheap solution and does not preclude using the programming cable. I appreciate people making suggestions, but I don't understand what is wrong with using the FTDI chip on the board. There are many ways to skin a cat, but in this case the FTDI approach is simpler and more direct. To use the MCU to either program the FPGA or to program an SPI flash requires code to be written and debugged. The FTDI chip should just work. No? -- 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 18, 20202020-09-18
Reply by ●September 18, 20202020-09-18
On Friday, September 18, 2020 at 4:26:20 AM UTC-4, lasselangwad...@gmail.com wrote:> 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/openFPGALoaderWhich cable is the "standard" FTDI cable? Do you mean the C232HM-xxxxx-x? That's an option, but why not use it with the Gowin software? How is openFPGAloader any better? Even then we would need to buy $40 cables for everyone. Why isn't a $5 chip a good solution? Are there cheaper "standard" FTDI cables? -- Rick C. -++ Get 1,000 miles of free Supercharging -++ Tesla referral code - https://ts.la/richard11209
Reply by ●September 18, 20202020-09-18
fredag den 18. september 2020 kl. 18.56.32 UTC+2 skrev Rick C:> On Friday, September 18, 2020 at 4:26:20 AM UTC-4, lasselangwad...@gmail.com wrote: > > 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 > > Which cable is the "standard" FTDI cable? Do you mean the C232HM-xxxxx-x? That's an option, but why not use it with the Gowin software? How is openFPGAloader any better? Even then we would need to buy $40 cables for everyone. Why isn't a $5 chip a good solution? > > Are there cheaper "standard" FTDI cables? > la/richard11209https://www.digikey.dk/product-detail/da/ftdi-future-technology-devices-international-ltd/TTL-234X-3V3/768-1319-ND/6823715?utm_source=oemsecrets&utm_medium=aggregator&utm_campaign=buynow
Reply by ●September 18, 20202020-09-18
On Friday, September 18, 2020 at 5:37:23 PM UTC-4, lasselangwad...@gmail.co= m wrote:> fredag den 18. september 2020 kl. 18.56.32 UTC+2 skrev Rick C: > > On Friday, September 18, 2020 at 4:26:20 AM UTC-4, lasselangwad...@gmai=l.com wrote:> > > 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, lasselang=wad...@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, lassela=ngwad...@gmail.com wrote:> > > > > > > > > tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev R=ick C:> > > > > > > > > > On Tuesday, September 15, 2020 at 1:03:17 PM UTC-4, las=selangwad...@gmail.com wrote:> > > > > > > > > > > tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skr=ev Rick C:> > > > > > > > > > > > Gowin seems to have some nice configuration modes i=n their parts. Of course they have an auto boot from internal flash and JT= AG can be used to program either the RAM or the Flash. They also have mast= er 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 fal= l back to internal auto boot. But... they don't always make all of the mod= e control pins available and/or the pins needed for the various interfaces.= =20> > > > > > > > > > > >=20 > > > > > > > > > > > > In the QN88 package they leave out Mode2 so only th=e 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 t= o emulate a JTAG driver! They also don't make any of this clear from the d= ocumentation. You have to read the pin list and figure out that various si= gnals are missing. Each package and even each part are different. =20> > > > > > > > > > > >=20 > > > > > > > > > > > > It is a chore figuring this stuff out. Many aspect=s of these devices are inconsistent. =20> > > > > > > > > > > >=20 > > > > > > > > > > >=20 > > > > > > > > > > > just make MCU SPI slave ? > > > > > > > > > > >=20 > > > > > > > > > > > JTAG shouldn't be too terrible to do, https://www.eev=blog.com/forum/projects/(poll)-fpga-board-form-factor/?action=3Ddlattach;at= tach=3D928670> > > > > > > > > >=20 > > > > > > > > > > How does that work? The MCU can pump out addressed dat=a at Mbps? That's a tough thing to do in general and if it has anything el= se to do - even tougher. I guess when programming the FPGA there isn't any= thing else for the MCU to do, so it just has to retrieve the appropriate da= ta quickly enough to get it into the SPI hardware to ship out. I don't kno= w how much time that gives. I haven't seen the interface spec before. =20> > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > you can usually setup a DMA to do most of the work > > > > > > > >=20 > > > > > > > > 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?= =20> > > > > > > >=20 > > > > > > >=20 > > > > > > > usually the fpga just sends a 0x03 or 0x0b read command and a=24 bit address=20> > > > > > > and then expect data from that address forward as it keeps on=clocking> > > > > > >=20 > > > > > > > you can usually ignore the received data and just send the co=nfig data with dummy bytes to account for the extra 8+24 clocks> > > > > > >=20 > > > > > > > don't now about gowin but xilinx will also ignore data until =it sees the bitpattern of the bitfile preamble> > > > > >=20 > > > > > > Ok, that's an interesting idea. But still, this design won't u=se 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 appli= cation programming the FPGA will require jumpers or an outside cable or som= ething to assure the software can't corrupt the FPGA.=20> > > > > >=20 > > > > >=20 > > > > > the bit file has crc too, atleast for xilinx so I'd assume everyo=ne does=20> > > > > since a random bitfile would be bad news.=20 > > > > >=20 > > > > > but anyway, if the fpga need to be programmed from the cpu the cp=u needs=20> > > > > control of the pin initiating configuration, if the fpga is criti=cal that=20> > > > > is probably a bad idea > > > >=20 > > > > The programming is only during development. So a jumper would be u=sed to isolate the FPGA during production. =20> > > >=20 > > > > Presently my thinking is to include an FTDI chip to allow programmi=ng with a simple USB port during development. Not installed for product an= d using a cabled programmer.=20> > > >=20 > > >=20 > > > why not use the standard ftdi cable, then you'll only need a header a=nd it'll also give pads for pogo pins in production> > >=20 > > > https://github.com/trabucayre/openFPGALoader > >=20 > > Which cable is the "standard" FTDI cable? Do you mean the C232HM-xxxxx=-x? That's an option, but why not use it with the Gowin software? How is = openFPGAloader any better? Even then we would need to buy $40 cables for e= veryone. Why isn't a $5 chip a good solution? =20> >=20 > > Are there cheaper "standard" FTDI cables?=20 > > la/richard11209 >=20 > https://www.digikey.dk/product-detail/da/ftdi-future-technology-devices-i=nternational-ltd/TTL-234X-3V3/768-1319-ND/6823715?utm_source=3Doemsecrets&u= tm_medium=3Daggregator&utm_campaign=3Dbuynow We don't seem to be talking about the same thing. I didn't mean a any cabl= e with the FTDI name on it. I meant the FTDI 2232H chip on a cable for sig= nificantly less than the C232HM cable. Even that cable may or may not work= . I wrote the Gowin contact and specifically asked about this cable and hi= s reply was that their software will work with the FT2232H chip which this = cable doesn't have. Searches on the internet didn't turn up anything reall= y. There are a number of small boards claiming to use the FT2232 chip. Bu= t they are not overly cheap and will require some wiring.=20 This is not just another serial cable. =20 --=20 Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
Reply by ●September 19, 20202020-09-19
On 18/09/2020 17:51, Rick C wrote:> On Friday, September 18, 2020 at 7:43:07 AM UTC-4, 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. > > This device is a Gowin GW1N series product. They provide an $80 programming cable or use the FTDI chip in their board products as does Trenz. Gowin can't rely on any other mode for programming their devices because SPI slave mode is not supported on all devices. It seems insane, but they have five programming modes not counting JTAG and Auto Boot (from internal flash) but one some devices/packages offer only one alternative because they don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a single mode pin, Mode 0. In that case Slave SPI is the only other choice than Auto Boot. In other packages the only other choice is Master SPI or only CPU 8 bit parallel. Heck, in some packages the mode pin out changes between devices! Strange. > > So I am left with the choices of buying an $80 cable for everyone, or adding the FTDI chip to the board. I'll add the chip unless someone has a truly better idea. It seems to be the cheap solution and does not preclude using the programming cable. > > I appreciate people making suggestions, but I don't understand what is wrong with using the FTDI chip on the board. There are many ways to skin a cat, but in this case the FTDI approach is simpler and more direct. To use the MCU to either program the FPGA or to program an SPI flash requires code to be written and debugged. The FTDI chip should just work. No? >I don't see any huge problems with putting the FTDI chip on the board. The downside will be the space it takes up but I guess you're OK with that. Another possibility is to buy a ready made FT2232H board and put just JTAG pin access on your board. I don't think this would save any money but it would allow you to keep your own board a bit simpler. FTDI do a an FT2232H min module (about £20 one off from Mouser) MK
Reply by ●September 19, 20202020-09-19
lørdag den 19. september 2020 kl. 10.10.14 UTC+2 skrev Michael Kellett:> On 18/09/2020 17:51, Rick C wrote: > > On Friday, September 18, 2020 at 7:43:07 AM UTC-4, 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. > > > > This device is a Gowin GW1N series product. They provide an $80 programming cable or use the FTDI chip in their board products as does Trenz. Gowin can't rely on any other mode for programming their devices because SPI slave mode is not supported on all devices. It seems insane, but they have five programming modes not counting JTAG and Auto Boot (from internal flash) but one some devices/packages offer only one alternative because they don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a single mode pin, Mode 0. In that case Slave SPI is the only other choice than Auto Boot. In other packages the only other choice is Master SPI or only CPU 8 bit parallel. Heck, in some packages the mode pin out changes between devices! Strange. > > > > So I am left with the choices of buying an $80 cable for everyone, or adding the FTDI chip to the board. I'll add the chip unless someone has a truly better idea. It seems to be the cheap solution and does not preclude using the programming cable. > > > > I appreciate people making suggestions, but I don't understand what is wrong with using the FTDI chip on the board. There are many ways to skin a cat, but in this case the FTDI approach is simpler and more direct. To use the MCU to either program the FPGA or to program an SPI flash requires code to be written and debugged. The FTDI chip should just work. No? > > > I don't see any huge problems with putting the FTDI chip on the board. > The downside will be the space it takes up but I guess you're OK with that. > Another possibility is to buy a ready made FT2232H board and put just > JTAG pin access on your board. I don't think this would save any money > but it would allow you to keep your own board a bit simpler. > FTDI do a an FT2232H min module (about £20 one off from Mouser) >so it is one $20 cable or a $5 part on every board for something that is needed once
Reply by ●September 21, 20202020-09-21
On Saturday, September 19, 2020 at 4:10:14 AM UTC-4, Michael Kellett wrote:> On 18/09/2020 17:51, Rick C wrote: > > On Friday, September 18, 2020 at 7:43:07 AM UTC-4, 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. > > > > This device is a Gowin GW1N series product. They provide an $80 programming cable or use the FTDI chip in their board products as does Trenz. Gowin can't rely on any other mode for programming their devices because SPI slave mode is not supported on all devices. It seems insane, but they have five programming modes not counting JTAG and Auto Boot (from internal flash) but one some devices/packages offer only one alternative because they don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a single mode pin, Mode 0. In that case Slave SPI is the only other choice than Auto Boot. In other packages the only other choice is Master SPI or only CPU 8 bit parallel. Heck, in some packages the mode pin out changes between devices! Strange. > > > > So I am left with the choices of buying an $80 cable for everyone, or adding the FTDI chip to the board. I'll add the chip unless someone has a truly better idea. It seems to be the cheap solution and does not preclude using the programming cable. > > > > I appreciate people making suggestions, but I don't understand what is wrong with using the FTDI chip on the board. There are many ways to skin a cat, but in this case the FTDI approach is simpler and more direct. To use the MCU to either program the FPGA or to program an SPI flash requires code to be written and debugged. The FTDI chip should just work. No? > > > I don't see any huge problems with putting the FTDI chip on the board. > The downside will be the space it takes up but I guess you're OK with that. > Another possibility is to buy a ready made FT2232H board and put just > JTAG pin access on your board. I don't think this would save any money > but it would allow you to keep your own board a bit simpler. > FTDI do a an FT2232H min module (about £20 one off from Mouser) > > MKSpace on this board is not an issue, it's about 4" x 8", aka 100 mm x 200 mm because of two LCD displays mounted on it. The guy driving a lot of the outline details is an ME and might not realize the cost of the board is directly related to the area. That's ok, we are getting prototypes for free from JLCPBC with assembly of any parts they have in inventory. However we slice it $5 for a chip is cheaper than the cost of the module and simpler since it only required the use of a USB cable. Dongles are nice in general, but we will have a number of people mucking with prototypes. So it's just simpler to put the chip on the board. I just want to be sure I get the design right so it works without debug. I'll essentially lift the design from the Gown eval board designs. Even Trenz provides schematics which are the same as the Gowin boards as far as I can see. Just for grins I may buy an FTDI cable that uses the single channel version of the chip. It may not work because there is a JTAG enable pin that may need to be controlled on a specific pin on the chip. I don't see that on the Gowin boards schematics while the Trenz schematic connects it to the external connector, but not the FTDI chip. Go figure! No pull down but the pin has an internal pull up which deactivates it. I'm very confused. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
Reply by ●September 21, 20202020-09-21
On Saturday, September 19, 2020 at 7:02:44 AM UTC-4, lasselangwad...@gmail.= com wrote:> l=C3=B8rdag den 19. september 2020 kl. 10.10.14 UTC+2 skrev Michael Kelle=tt:> > On 18/09/2020 17:51, Rick C wrote: > > > On Friday, September 18, 2020 at 7:43:07 AM UTC-4, 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 t=o do> > >>> - even tougher. I guess when programming the FPGA there isn't anyt=hing> > >>> 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 b=efore.> > >> > > >> The iCE40, and probably other FPGAs, use SPI slave mode for cable ba=sed> > >> 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. > > >=20 > > > This device is a Gowin GW1N series product. They provide an $80 prog=ramming cable or use the FTDI chip in their board products as does Trenz. = Gowin can't rely on any other mode for programming their devices because SP= I slave mode is not supported on all devices. It seems insane, but they ha= ve five programming modes not counting JTAG and Auto Boot (from internal fl= ash) but one some devices/packages offer only one alternative because they = don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a= single mode pin, Mode 0. In that case Slave SPI is the only other choice = than Auto Boot. In other packages the only other choice is Master SPI or o= nly CPU 8 bit parallel. Heck, in some packages the mode pin out changes be= tween devices! Strange.> > >=20 > > > So I am left with the choices of buying an $80 cable for everyone, or=adding the FTDI chip to the board. I'll add the chip unless someone has a= truly better idea. It seems to be the cheap solution and does not preclud= e using the programming cable.> > >=20 > > > I appreciate people making suggestions, but I don't understand what i=s wrong with using the FTDI chip on the board. There are many ways to skin= a cat, but in this case the FTDI approach is simpler and more direct. To = use the MCU to either program the FPGA or to program an SPI flash requires = code to be written and debugged. The FTDI chip should just work. No?> > >=20 > > I don't see any huge problems with putting the FTDI chip on the board. > > The downside will be the space it takes up but I guess you're OK with t=hat.> > Another possibility is to buy a ready made FT2232H board and put just==20> > JTAG pin access on your board. I don't think this would save any money==20> > but it would allow you to keep your own board a bit simpler. > > FTDI do a an FT2232H min module (about =C2=A320 one off from Mouser) > >=20 >=20 > so it is one $20 cable or a $5 part on every board for something that is==20> needed onceWhy would it be needed to assemble that part on every board made???=20 I made that very clear in a prior post on this. USB cable to on board chip= for prototyping. External programming cable for production. Same board, = different BOM.=20 It's also not one $20 cable as I have pointed out several times. The team = will each need to program the FPGAs as updates are made. So it would likel= y be a half dozen cables or more. The real advantage of the chip on board = is the lack of needing to track the durn special purpose cables. Any USB m= icro cable will work. Simple, cheap and optimally effective. I can't see = doing it any other way on this design.=20 Explain to me what I'm not getting.=20 --=20 Rick C. ++- Get 1,000 miles of free Supercharging ++- Tesla referral code - https://ts.la/richard11209
