Gowin FPGA Oddities...

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

--

Rick C.

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

 

[Michael Kellett]

On 15/09/2020 04:26, Rick C wrote:

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.

I get the impression that GOWIN (somewhat like Lattice) are very much
driven by what major customers want.
In another place we had a design which gave the micro access to the
FPGA\'s slave flash device. The micro could hold the FPGA inert, burn the
SPI flash chip and then allow the FPGA to boot from it.
I once did a JTAG driver for an Atmel ARM micro - not an experience I
wish to repeat !
With a decent logic analyser you could probably reverse engineer the
JTAG coding if you really had to - but 8 pin flash chips are so cheap it
hardly seems worth the effort.

MK

 

[Johann Klammer]

On 09/15/2020 05:26 AM, Rick C wrote:

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.

Do they have a BSDL file describing the register chain?

 

[Jan Coombs]

On Tue, 15 Sep 2020 09:14:41 +0100
Michael Kellett <mk@mkesc.co.uk> wrote:

I get the impression that GOWIN (somewhat like Lattice) are very much
driven by what major customers want.

Fair comment, but there are other ways to get info and support. If not
now, then probably soon:

synth_gowin - synthesis for Gowin FPGAs
http://www.clifford.at/yosys/cmd_synth_gowin.html

Project Apicula - Documentation of the Gowin FPGA bitstream format.
Project Apicula uses a combination of fuzzing and parsing of the vendor
data files to find the meaning of all the bits in the bitstream.
https://github.com/YosysHQ/apicula

Progress - Improvements for gowin support #1449
https://github.com/YosysHQ/yosys/pull/1449

Dev Board question:
https://www.eevblog.com/forum/fpga/gowin-fpgas/

Rumor: GoWin FPGAs are essentially based on SiliconBlue iCE55 (previous
generation of Lattice iCE40) fabric matrix, with IO Logic lifted from
Mach and DSP Lifted from ECP.
https://www.eevblog.com/forum/fpga/gowin-fpgas/


Jan Coombs
--

 

[Rick C]

On Tuesday, September 15, 2020 at 4:14:50 AM UTC-4, Michael Kellett wrote:

On 15/09/2020 04:26, Rick C wrote:
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.

I get the impression that GOWIN (somewhat like Lattice) are very much
driven by what major customers want.
In another place we had a design which gave the micro access to the
FPGA\'s slave flash device. The micro could hold the FPGA inert, burn the
SPI flash chip and then allow the FPGA to boot from it.
I once did a JTAG driver for an Atmel ARM micro - not an experience I
wish to repeat !
With a decent logic analyser you could probably reverse engineer the
JTAG coding if you really had to - but 8 pin flash chips are so cheap it
hardly seems worth the effort.

MK

The flash chip has to be burned via a JTAG programmer connected to the FPGA.. It would be nice to have the option of programming the FPGA and/or flash chip from the MCU in many applications. I need to look harder at the 100 pin QFP. That may be a better package for this project and others. It supports all the slave SPI pins. Here the oddity is they only bring out a single Mode pin allowing JTAG, Auto Boot and Slave SPI, no Master SPI mode. Very bizarre.

I think the support engineer gets tired of my questions. The answer to my question about the auto boot configuration time was odd and I didn\'t understand it. While the data is transferred from flash to RAM internally, it is done is a serial like manner and depends on the clock rate selected. From what I\'m being told the data transfer is in bytes, so 8x the clock rate in bps. The clock rate is selected in the programming software, so it must be in the bit stream.

There seem to be a number of unexpected \"oddities\" about these parts. It may well be that some customer required a specific pin out in a given package and so this is now what is sold to everyone. I recall late last year when I contacted them they were essentially looking for \"whale\" customers which dictated when they brought out what chip in what package. I guess the whales also dictate which config modes are provided in a package.

I am finding that the Compatibility Comparison guide is essential. If all your I/Os are the same voltage as the Vccx it\'s no big deal, but they switch up Vccx and Vccon between different die in the same package. So watch out if you want to have device size options!

--

Rick C.

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

 

[Rick C]

On Tuesday, September 15, 2020 at 10:11:16 AM UTC-4, Johann Klammer wrote:

On 09/15/2020 05:26 AM, Rick C wrote:
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.

Do they have a BSDL file describing the register chain?

I haven\'t looked.

--

Rick C.

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

 

[Rick C]

On Tuesday, September 15, 2020 at 10:53:58 AM UTC-4, Jan Coombs wrote:

On Tue, 15 Sep 2020 09:14:41 +0100
Michael Kellett <mk@mkesc.co.uk> wrote:

I get the impression that GOWIN (somewhat like Lattice) are very much
driven by what major customers want.

Fair comment, but there are other ways to get info and support. If not
now, then probably soon:

synth_gowin - synthesis for Gowin FPGAs
http://www.clifford.at/yosys/cmd_synth_gowin.html

Project Apicula - Documentation of the Gowin FPGA bitstream format.
Project Apicula uses a combination of fuzzing and parsing of the vendor
data files to find the meaning of all the bits in the bitstream.
https://github.com/YosysHQ/apicula

Progress - Improvements for gowin support #1449
https://github.com/YosysHQ/yosys/pull/1449

Dev Board question:
https://www.eevblog.com/forum/fpga/gowin-fpgas/

Rumor: GoWin FPGAs are essentially based on SiliconBlue iCE55 (previous
generation of Lattice iCE40) fabric matrix, with IO Logic lifted from
Mach and DSP Lifted from ECP.
https://www.eevblog.com/forum/fpga/gowin-fpgas/

I\'ll read the links, but I don\'t think they are too literally based on the Lattice/IceBlue devices. The static power consumption is much higher if I\'m understanding the data sheets. The iCE55 parts were well under 100 uA with a boost up to 100 uA in the iCE40 line once Lattice took them over (likely to ease production testing rather than actual silicon changes). The Gowin parts are in the mA range. But I do find their data sheets hard to read.. Lots of slightly unfamiliar terminology which makes me uncertain what exactly they are measuring.

Thanks for the links.

--

Rick C.

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

 

[server]

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

 

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

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.

--

Rick C.

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

 

[server]

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

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)

 

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

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

 

[server]

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

 

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

--

Rick C.

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

 

[server]

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

 

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

--

Rick C.

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

 

[David Brown]

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.

 

[server]

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

 

[Jan Coombs]

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

 

[David Brown]

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.

 

[Michael Kellett]

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