Gowin FPGA Oddities

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

k C:

Rick C:

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.

auto boot and the two SPI modes are selectable. Then they leave out the sl ave serial input pin so only auto boot, master SPI and JTAG are left. If y ou 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 doc umentation. You have to read the pin list and figure out that various sign als are missing. Each package and even each part are different.

of these devices are inconsistent.

ch=928670

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 anyth ing 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.

lieve. 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?

locking

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

sees the bitpattern of the bitfile preamble

it other than in development maybe. The FPGA has to be paranoid and not t rust the software so it can be independently validated. In the end applica tion programming the FPGA will require jumpers or an outside cable or somet hing to assure the software can't corrupt the FPGA.

does

needs

l that

d to isolate the FPGA during production.

with a simple USB port during development. Not installed for product and using a cabled programmer.

it'll also give pads for pogo pins in production

? That's an option, but why not use it with the Gowin software? How is op enFPGAloader any better? Even then we would need to buy $40 cables for eve ryone. Why isn't a $5 chip a good solution?

ick C:

ev Rick C:

n their parts. Of course they have an auto boot from internal flash and JT AG can be used to program either the RAM or the Flash. They also have mast er and slave SPI modes, a serial mode that daisy chains multiple FPGAs and a parallel bus mode along with a mode to try reading external flash and fal l back to internal auto boot. But... they don't always make all of the mod e control pins available and/or the pins needed for the various interfaces.

e auto boot and the two SPI modes are selectable. Then they leave out the slave serial input pin so only auto boot, master SPI and JTAG are left. If you want to configure the part from an MCU you are stuck unless you want t o emulate a JTAG driver! They also don't make any of this clear from the d ocumentation. You have to read the pin list and figure out that various si gnals are missing. Each package and even each part are different.

s of these devices are inconsistent.

tach=928670

a at Mbps? That's a tough thing to do in general and if it has anything el se to do - even tougher. I guess when programming the FPGA there isn't any thing else for the MCU to do, so it just has to retrieve the appropriate da ta quickly enough to get it into the SPI hardware to ship out. I don't kno w how much time that gives. I haven't seen the interface spec before.

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?

clocking

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

it sees the bitpattern of the bitfile preamble

se it other than in development maybe. The FPGA has to be paranoid and not trust the software so it can be independently validated. In the end appli cation programming the FPGA will require jumpers or an outside cable or som ething to assure the software can't corrupt the FPGA.

ne does

u needs

cal that

sed to isolate the FPGA during production.

ng with a simple USB port during development. Not installed for product an d using a cabled programmer.

nd it'll also give pads for pogo pins in production

-x? That's an option, but why not use it with the Gowin software? How is openFPGAloader any better? Even then we would need to buy $40 cables for e veryone. Why isn't a $5 chip a good solution?

We don't seem to be talking about the same thing. I didn't mean a any cabl e with the FTDI name on it. I meant the FTDI 2232H chip on a cable for sig nificantly less than the C232HM cable. Even that cable may or may not work . I wrote the Gowin contact and specifically asked about this cable and hi s reply was that their software will work with the FT2232H chip which this cable doesn't have. Searches on the internet didn't turn up anything reall y. There are a number of small boards claiming to use the FT2232 chip. Bu t they are not overly cheap and will require some wiring.

This is not just another serial cable.

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.

MK

do

ng

ta

ore.

ll

mming cable or use the FTDI chip in their board products as does Trenz. Go win 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 flas h) but one some devices/packages offer only one alternative because they do n't pin out all mode inputs. Even on a 100 pin QFP they only bring out a s ingle mode pin, Mode 0. In that case Slave SPI is the only other choice th an Auto Boot. In other packages the only other choice is Master SPI or onl y CPU 8 bit parallel. Heck, in some packages the mode pin out changes betw een devices! Strange.

dding the FTDI chip to the board. I'll add the chip unless someone has a t ruly better idea. It seems to be the cheap solution and does not preclude using the programming cable.

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 us e the MCU to either program the FPGA or to program an SPI flash requires co de to be written and debugged. The FTDI chip should just work. No?

t.

so it is one $20 cable or a $5 part on every board for something that is needed once

do

ng

ta

ore.

ll

mming cable or use the FTDI chip in their board products as does Trenz. Go win 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 flas h) but one some devices/packages offer only one alternative because they do n't pin out all mode inputs. Even on a 100 pin QFP they only bring out a s ingle mode pin, Mode 0. In that case Slave SPI is the only other choice th an Auto Boot. In other packages the only other choice is Master SPI or onl y CPU 8 bit parallel. Heck, in some packages the mode pin out changes betw een devices! Strange.

dding the FTDI chip to the board. I'll add the chip unless someone has a t ruly better idea. It seems to be the cheap solution and does not preclude using the programming cable.

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 us e the MCU to either program the FPGA or to program an SPI flash requires co de to be written and debugged. The FTDI chip should just work. No?

t.

Space on this board is not an issue, it's about 4" x 8", aka 100 mm x 200 m m 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 dir ectly related to the area. That's ok, we are getting prototypes for free f rom 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 an d 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. S o 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 w hich 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 t he Gowin boards schematics while the Trenz schematic connects it to the ext ernal connector, but not the FTDI chip. Go figure! No pull down but the p in has an internal pull up which deactivates it. I'm very confused.

tt:

o do

hing

data

efore.

sed

full

the

ramming cable or use the FTDI chip in their board products as does Trenz. Gowin can't rely on any other mode for programming their devices because SP I slave mode is not supported on all devices. It seems insane, but they ha ve five programming modes not counting JTAG and Auto Boot (from internal fl ash) but one some devices/packages offer only one alternative because they don't pin out all mode inputs. Even on a 100 pin QFP they only bring out a single mode pin, Mode 0. In that case Slave SPI is the only other choice than Auto Boot. In other packages the only other choice is Master SPI or o nly CPU 8 bit parallel. Heck, in some packages the mode pin out changes be tween devices! Strange.

adding the FTDI chip to the board. I'll add the chip unless someone has a truly better idea. It seems to be the cheap solution and does not preclud e using the programming cable.

s wrong with using the FTDI chip on the board. There are many ways to skin a cat, but in this case the FTDI approach is simpler and more direct. To use the MCU to either program the FPGA or to program an SPI flash requires code to be written and debugged. The FTDI chip should just work. No?

hat.

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 likel y be a half dozen cables or more. The real advantage of the chip on board is the lack of needing to track the durn special purpose cables. Any USB m icro cable will work. Simple, cheap and optimally effective. I can't see doing it any other way on this design.

Explain to me what I'm not getting.