Gowin FPGA Oddities

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

Do they have a BSDL file describing the register chain?

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

synth_gowin - synthesis for Gowin FPGAs

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.

Progress - Improvements for gowin support #1449

Dev Board question:

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.

Jan Coombs

ourse they have an auto boot from internal flash and JTAG can be used to pr ogram either the RAM or the Flash. They also have master and slave SPI mod es, 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 a uto boot. But... they don't always make all of the mode control pins avail able and/or the pins needed for the various interfaces.

two SPI modes are selectable. Then they leave out the slave serial input p in so only auto boot, master SPI and JTAG are left. If you want to configu re the part from an MCU you are stuck unless you want to emulate a JTAG dri ver! They also don't make any of this clear from the documentation. You h ave to read the pin list and figure out that various signals are missing. Each package and even each part are different.

re inconsistent.

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 sup ports all the slave SPI pins. Here the oddity is they only bring out a sin gle Mode pin allowing JTAG, Auto Boot and Slave SPI, no Master SPI mode. V ery 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 unders tand 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 b e in the bit stream.

There seem to be a number of unexpected "oddities" about these parts. It m ay well be that some customer required a specific pin out in a given packag e and so this is now what is sold to everyone. I recall late last year whe n I contacted them they were essentially looking for "whale" customers whic h dictated when they brought out what chip in what package. I guess the wh ales 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 switc h up Vccx and Vccon between different die in the same package. So watch ou t if you want to have device size options!

--

  Rick C. 

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

ourse they have an auto boot from internal flash and JTAG can be used to pr ogram either the RAM or the Flash. They also have master and slave SPI mod es, 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 a uto boot. But... they don't always make all of the mode control pins avail able and/or the pins needed for the various interfaces.

two SPI modes are selectable. Then they leave out the slave serial input p in so only auto boot, master SPI and JTAG are left. If you want to configu re the part from an MCU you are stuck unless you want to emulate a JTAG dri ver! They also don't make any of this clear from the documentation. You h ave to read the pin list and figure out that various signals are missing. Each package and even each part are different.

re inconsistent.

I haven't looked.

--

  Rick C. 

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

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 wi th a boost up to 100 uA in the iCE40 line once Lattice took them over (like ly to ease production testing rather than actual silicon changes). The Gow in 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 ex actly they are measuring.

Thanks for the links.

--

  Rick C. 

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

tirsdag den 15. september 2020 kl. 05.26.33 UTC+2 skrev Rick C:

rse they have an auto boot from internal flash and JTAG can be used to prog ram 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 al ong with a mode to try reading external flash and fall back to internal aut o boot. But... they don't always make all of the mode control pins availab le and/or the pins needed for the various interfaces.

o 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 drive r! They also don't make any of this clear from the documentation. You hav e to read the pin list and figure out that various signals are missing. Ea ch package and even each part are different.

inconsistent.

just make MCU SPI slave ?

JTAG shouldn't be too terrible to do,

ourse they have an auto boot from internal flash and JTAG can be used to pr ogram either the RAM or the Flash. They also have master and slave SPI mod es, 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 a uto boot. But... they don't always make all of the mode control pins avail able and/or the pins needed for the various interfaces.

two SPI modes are selectable. Then they leave out the slave serial input p in so only auto boot, master SPI and JTAG are left. If you want to configu re the part from an MCU you are stuck unless you want to emulate a JTAG dri ver! They also don't make any of this clear from the documentation. You h ave to read the pin list and figure out that various signals are missing. Each package and even each part are different.

re inconsistent.

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 toug her. I guess when programming the FPGA there isn't anything else for the M CU 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 t hem away for one or two I/Os which can be reclaimed after booting or even b efore if not used in the mode selected.

--

  Rick C. 

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

tirsdag den 15. september 2020 kl. 21.29.32 UTC+2 skrev Rick C:

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 m odes, a serial mode that daisy chains multiple FPGAs and a parallel bus mod e 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 ava ilable and/or the pins needed for the various interfaces.

e 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 confi gure the part from an MCU you are stuck unless you want to emulate a JTAG d river! 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.

are inconsistent.

a tough thing to do in general and if it has anything else to do - even to ugher. 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 th at gives. I haven't seen the interface spec before.

you can usually setup a DMA to do most of the work

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)

Of course they have an auto boot from internal flash and JTAG can be used t o 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 m ode along with a mode to try reading external flash and fall back to intern al auto boot. But... they don't always make all of the mode control pins a vailable and/or the pins needed for the various interfaces.

the two SPI modes are selectable. Then they leave out the slave serial inp ut pin so only auto boot, master SPI and JTAG are left. If you want to con figure 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. Y ou have to read the pin list and figure out that various signals are missin g. Each package and even each part are different.

es are inconsistent.

'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 t he MCU to do, so it just has to retrieve the appropriate data quickly enoug h 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.

Emulating a serial prom requires implementing a protocol I believe. Is tha t 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?

ss them away for one or two I/Os which can be reclaimed after booting or ev en before if not used in the mode selected.

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 m aster 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 guessi ng 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 ha ve lots of it, but finding it is a chore with it only being accessed throug h 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 programm ers 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 th ey use on some of the Gowin boards and the Trenz board. I believe the Sipe ed 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 possi bly go wrong is a bit overwhelming.

--

  Rick C. 

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

onsdag den 16. september 2020 kl. 02.54.06 UTC+2 skrev Rick C:

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 S PI 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 inte rnal auto boot. But... they don't always make all of the mode control pins available and/or the pins needed for the various interfaces.

d the two SPI modes are selectable. Then they leave out the slave serial i nput pin so only auto boot, master SPI and JTAG are left. If you want to c onfigure the part from an MCU you are stuck unless you want to emulate a JT AG 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 miss ing. Each package and even each part are different.

ices are inconsistent.

at's a tough thing to do in general and if it has anything else to do - eve n 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 eno ugh to get it into the SPI hardware to ship out. I don't know how much tim e that gives. I haven't seen the interface spec before.

hat possible with the timing constraints? Or is there a way to make the FP GA 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 addres s 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 bi tpattern of the bitfile preamble

s. Of course they have an auto boot from internal flash and JTAG can be us ed 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 b us mode along with a mode to try reading external flash and fall back to in ternal auto boot. But... they don't always make all of the mode control pi ns available and/or the pins needed for the various interfaces.

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 mi ssing. Each package and even each part are different.

evices are inconsistent.

0

That's a tough thing to do in general and if it has anything else to do - e ven tougher. I guess when programming the FPGA there isn't anything else f or the MCU to do, so it just has to retrieve the appropriate data quickly e nough to get it into the SPI hardware to ship out. I don't know how much t ime that gives. I haven't seen the interface spec before.

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?

ess

th dummy bytes to account for the extra 8+24 clocks

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 s oftware so it can be independently validated. In the end application progr amming the FPGA will require jumpers or an outside cable or something to as sure the software can't corrupt the FPGA.

--

  Rick C. 

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

torsdag den 17. september 2020 kl. 19.32.50 UTC+2 skrev Rick C:

rts. 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 sla ve 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.

t and the two SPI modes are selectable. Then they leave out the slave seri al 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 documentati on. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different.

devices are inconsistent.

670

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.

Is that possible with the timing constraints? Or is there a way to make th e FPGA wait while the MCU reads the command and sets up the DMA?

dress

with dummy bytes to account for the extra 8+24 clocks

e bitpattern of the bitfile preamble

r 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 pro gramming 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

C:

parts. Of course they have an auto boot from internal flash and JTAG can b e used to program either the RAM or the Flash. They also have master and s lave SPI modes, a serial mode that daisy chains multiple FPGAs and a parall el bus mode along with a mode to try reading external flash and fall back t o internal auto boot. But... they don't always make all of the mode contro l pins available and/or the pins needed for the various interfaces.

oot and the two SPI modes are selectable. Then they leave out the slave se rial input pin so only auto boot, master SPI and JTAG are left. If you wan t to configure the part from an MCU you are stuck unless you want to emulat e a JTAG driver! They also don't make any of this clear from the documenta tion. You have to read the pin list and figure out that various signals ar e missing. Each package and even each part are different.

se devices are inconsistent.

28670

s? 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 el se for the MCU to do, so it just has to retrieve the appropriate data quick ly enough to get it into the SPI hardware to ship out. I don't know how mu ch time that gives. I haven't seen the interface spec before.

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?

address

g

a with dummy bytes to account for the extra 8+24 clocks

the bitpattern of the bitfile preamble

her than in development maybe. The FPGA has to be paranoid and not trust t he software so it can be independently validated. In the end application p rogramming the FPGA will require jumpers or an outside cable or something t o assure the software can't corrupt the FPGA.

The programming is only during development. So a jumper would be used to i solate 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

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.

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.

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.

fredag den 18. september 2020 kl. 00.20.45 UTC+2 skrev Rick C:

k C:

r 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 para llel 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 cont rol pins available and/or the pins needed for the various interfaces.

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 w ant to configure the part from an MCU you are stuck unless you want to emul ate a JTAG driver! They also don't make any of this clear from the documen tation. You have to read the pin list and figure out that various signals are missing. Each package and even each part are different.

hese devices are inconsistent.

=928670

bps? 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 qui ckly 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.

e. Is that possible with the timing constraints? Or is there a way to mak e the FPGA wait while the MCU reads the command and sets up the DMA?

t address

ing

ata with dummy bytes to account for the extra 8+24 clocks

s the bitpattern of the bitfile preamble

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.

s s

at

isolate the FPGA during production.

h a simple USB port during development. Not installed for product and usin g 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

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

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.

Yes, that'll work - I suggested it in the second post in this thread ;-)

I've done it with Lattice (ECP3) parts.

MK