Gowin FPGA Oddities...

[Rick C]

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

 

[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?

--

Rick C.

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

 

[server]

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/richard11209

https://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

 

[Rick C]

On Friday, September 18, 2020 at 5:37:23 PM UTC-4, lasselangwad...@gmail.com 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...@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/richard11209

https://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

We don\'t seem to be talking about the same thing. I didn\'t mean a any cable with the FTDI name on it. I meant the FTDI 2232H chip on a cable for significantly 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 his 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 really. There are a number of small boards claiming to use the FT2232 chip. But they are not overly cheap and will require some wiring.

This is not just another serial cable.

--

Rick C.

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

 

[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)

MK

 

[server]

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

 

[Rick C]

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)

MK

Space 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

 

[Rick C]

On Saturday, September 19, 2020 at 7:02:44 AM UTC-4, lasselangwad...@gmail.com wrote:

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

Why would it be needed to assemble that part on every board made???

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.

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 likely 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 micro cable will work. Simple, cheap and optimally effective. I can\'t see doing it any other way on this design.

Explain to me what I\'m not getting.

--

Rick C.

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