Chinese FPGAs

[dominicbeesley]

I'm not sure how interesting this is to other but thought I'd share a brain-dump here in case others are in the same quandry I was a few months ago...

Some of my projects have been stalled for around 3 years due to the Intel/AMD FPGA chip shortage which doesn't seem to show much sign of clearing any time soon.

I've considered going back to try the Lattice devices which seem to be more readily available but when searching for them the other day on a call we spotted the Efinix and Gowin devices and that they have relatively cheap dev boards available.

I ordered both a SiPeed Tang Nano 9K for £22 via ebay from China which arrived in 10 days and an Efinix Xyloni dev board for £73 (inc VAT) from Digikey which arrived in 2 days (disappointingly not in a little metal tin as shown in Digikey but instead in a cute little cardboard box)

I'd been put off in the past by the licencing of the Efinix and Gowin development suites. However, Efinix have now made their suite free, you still need to request a licence but they send it out automatically and it covers all devices. Gowin, I'm still not so sure of - their free/educational software covers their smaller devices but you have to request a licence for larger devices - I've not tried this yet so can't say whether it covers all devices or what hoops need to be jumped through.

The other off-put was that I assumed that the datasheets and software help would be a badly translated minefield. This was partly my mistake in incorrectly equating Sipeed with Gowin. However, I have to say that the datasheets for the Chips and the instructions for the software suites have been a delight. The chip datasheets I have found far easier to navigate than Altera's. I've not tried the support Forums for either Efinix or Gowin yet but I have to say the Efinix forum looked a bit quiet so I'm not sure how much support there is to be had.

The development software has been a revelation - clear, easy to work out and much much much faster running than either Xilinx ISE, Altera Quartus or Lattice. Projects that would take many minutes to build on for example Quartus build in seconds on both the Efinix and Gowin platforms. The efinix also has a analysis/syntax checker that runs very quickly and make correcting my many simple errors so much less laborious than on Quartus. It seems to find many more errors on each pass, unlike Quartus that finds the first one and then gives up pretty quickly.

I quickly skipped through the examples for both boards and got everything working really quickly. The Efinix is probably slightly more of a fiddle as I had to mess around getting the FTDI USB driver set up correctly but nothing too onerous.

The Efinix has a really weird way of setting up PLLs and IO assignments but once I'd worked that out it actually is quite nice to use.

Performance wise I've only managed to get my project working at around 65MHz on both the Efinix and Gowin chips as opposed to 128MHz on the Intel MAX 10. However, I'm not sure if I've got the timing constraints working correctly as I'm getting confusing results from the reports.

On the whole I'd say both Efinix and Gowin are worth considering and given the wider availability of the chips and their relatively low cost I'll be trying them out on some projects in the near future!

Has anyone else tried any other "new" FPGA/CPLDs and got experiences to share? I'm always interested! I'd be especially interested to hear about SDC constraints and/or building using makefiles.

D

[BigEd]

(Thanks for the writeup!)

[a1exh]

I switched to Efinix Trion in my designs as did lots of AMD (Xilinx) Spartan users.

I did buy lots of SiPeed Tang 9k/20k dev kits for their form factor and that they were being used as cheaper RGB2HDMI alternatives during the RPi zero shortage.

Everyone I know has abandoned Lattice iCE40 because of its iCEcube2 tool licensing. There is a free tool chain called iCEStorm which uses the open source tools including yoSys but reports are it's unusable.

[hoglet]

Everyone I know has abandoned Lattice iCE40 because of its iCEcube2 tool licensing. There is a free tool chain called iCEStorm which uses the open source tools including yoSys but reports are it's unusable.

I'm interested to hear more about it being unusable. Do you have any more details or references?

Dave

[a1exh]

Everyone I know has abandoned Lattice iCE40 because of its iCEcube2 tool licensing. There is a free tool chain called iCEStorm which uses the open source tools including yoSys but reports are it's unusable.

I'm interested to here more about it being unusable. Do you have any more details or references?

Have a watch of this post from renowned FPGA developer TerribleFire aka Stephen Leary. At approx 7 minutes in he says that minor HDL changes and even ROM contents (though I find that very hard to understand) can result in non working images. Unlikely to be user error with such an experienced user but you never know.

https://youtu.be/we3pbEE3O4k

[BigEd]

(I thought we'd made good use of the open source ICE40 flow...)

[dominicbeesley]

Thanks for the replies, I'd used Lattice Diamond in the past with the MachXO3 chip - is that no longer free? (if not open source)

There's an open-source chain for the nano9k too but I've not tried that yet.

What I'm going to try to use next is the PSRAM on the Nano 9k - this looks quite interesting. 64Mbit of RAM on die...this however, is one area where the Gowin datasheets really are lacking. There's a few examples which appear to be out of date and an IP core but no real information on the timings required or how to setup the constraints file, or at least nothing I've found yet. I'm going to start with this project: https://github.com/zf3/psram-tang-nano-9k and see if I can get it patched into BeebFPGA - I've not quite worked out whether it will be low-latency enough.

D

[a1exh]

Do you do advance things with the iCE40 such as multiple clock domains, clock recovery, CDC, clock switching, mcp? These are the things that can blow up FPGA tools.

[hoglet]

Do you do advance things with the iCE40 such as multiple clock domains, clock recovery, CDC, clock switching, mcp? These are the things that can blow up FPGA tools.

Thank you for the link to Stephen's video.

Without knowning far more about the TF4060 than I do, it's hard to say whether his conclusion that the iCE40 tool chain is at fault is justified. Build-to-build instability of a system can be caused by many things. Different builds will have slightly different timings, but for that to have an effect on the overall system probably means something else is marginal.

My own experience of the iCEStorm toolchain about 6 years ago was mostly positive.

The key limitations then were:
- the frontend is Verilog only
- it doesn't support timing driven design

That said, I successfully used it for several projects for the BlackIce/BlackIce II FPGA board:
- Ice40Beeb
- Ice40Atom
- Ice40JupiterAce
- Ice40CPMZ80
- Ice40LogicSniffer

Although it doesn't support timing driven design, it does have a reasonable static timing analysys tool (icetime). So when you have a routed design you can find out how fast it will run, and the critical paths. If you stick with a conservative design style and avoid anything asynchronous then I found the results acceptable. Maybe I was just lucky...

It's a bit harder when timing paths involve off-chip components (such as asyncronous SRAMs). But I've not found that easy in any of the tool chains.

Dave

[dominicbeesley]

a1exh, not sure if that was addressed to me or Dave.

The only thing in my current projects I do that is in anyway odd is that instead of multiple clocks I tend to use a relatively fast (128MHz) system clock then divide that down with enables to things like the cpu core to run at an integer division. To get timing closure I need to add set_multicycle_path statements to the SDC for all the registers in the cpu. This has worked really well in the past with Altera, Xilinx and Lattice XO3 but doesn't seem to work as I expected in either Gowin or Efinix tools. When I add the constraint

Code: Select all

-from [get_regs cpu/*] -to [get_regs cpu/*]

it constrains and reports correctly but when I try

Code: Select all

-from [get_regs some_reg_outide_cpu] -to [get_regs cpu/*]

and vice-versa it doesn't meet timing and the "required" time on the failing path reported is still 7.8ns instead of the multiple that I'd expect. It may be user-error on my part but I've checked and rechecked that the selectors are correct. I've also tried with get_pins and constraining on the Q and D pins but still no joy.

Where I have clock domain crossing I've not actually encountered any problems so far but then I usually add some belt and braces clock crossing registers and just do set_false_path.

D

[a1exh]

instead of multiple clocks I tend to use a relatively fast (128MHz) system clock then divide that down with enables to things like the cpu core to run at an integer division. To get timing closure I need to add set_multicycle_path statements to the SDC for all the registers in the cpu. This has worked really well in the past with Altera, Xilinx

That is the technique that I try to use wherever possible. It is compulsory here to write all SystemVerilog sequential processes with a clock enable so that in the FPGA I can use a single clock and lower the effective clock rate using an enable.

It's also compulsory here to write the async reset of sequential processes using a pre-processor macro so I can change the polarity or remove the reset all together. You'd be amazed how much that can improve FPGA performance without changing behaviour too much.

[dominicbeesley]

Good to know I'm not doing something stupid then, I've still not sure got the multicycle thing working yet.

I had a few frustrating hours yesterday trying to get that psram project working. The original github project didn't work at all and failed timing closure by a mile. I've tinkered with it a bit but am struggling to get it working at more than 70MHz. Even when it says it is meeting timing, it looks to be reading back the first byte as zero but then getting subsequent bytes correct...I need to find (or make) a psram testbench

I'm also wondering if the educational version i have is somehow hampered in terms of timing optimisation as the original project must have worked.

D

[a1exh]

Which one? This one?

https://github.com/zf3/psram-tang-nano-9k

Or the original one from GoWin using encrypted Verilog? (Which is incredibly easy to decrypt if you ever need to)

https://www.gowinsemi.com/en/support/ip_detail/15/
https://github.com/zf3/some-tang-nano-9k-examples

[cmorley]

I bought a dev board with an iCE40HX8K on. I haven't done much with it TBH. I was a bit wary of Lattice changing the licensing on me again - I got stung by the ispLever Classic money grab... I think it still says it is free on the Lattice website dev board pages but £600/year ruined the economics of the stuff I was working on. Yep still says "free design tools" - liars.

For the ice40 I installed iceCube 2 which looks like a 90s GUI. I didn't try iceStorm.

[dominicbeesley]

I was a bit wary of Lattice changing the licensing on me again - I got stung by the ispLever Classic money grab...

Yes, I just saw that the other day and it has made me rule out Lattice altogether, a shame really

Which one? This one?

https://github.com/zf3/psram-tang-nano-9k

I've edited that one on a fork here https://github.com/dominicbeesley/psram-tang-nano-9k

I corrected a couple of bugs and added a dump of the first 16 bytes. I'm still getting bad reads as I push the clock up. The first pass below is at 54MHz, the second at 81MHz

Code: Select all

Writing...
000000 : c3
000001 : c2
000002 : c1
000003 : c0
000004 : c7
000005 : c6
000006 : c5
000007 : c4
000008 : cb
000009 : ca
00000a : c9
00000b : c8
00000c : cf
00000d : ce
00000e : cd
00000f : cc

Reading...
All done successfully.

And at 81MHz memory clock...

Code: Select all

Latency counters: write_1x=0ffd57, write_2x=0002a9, read_1x=0fffa1, read_2x=00005f
Writing...
000000 : 00
000001 : 00
000002 : 00
000003 : 00
000004 : dd
000005 : c6
000006 : 00
000007 : c4
000008 : 00
000009 : ca
00000a : 00
00000b : c8
00000c : 00
00000d : ce
00000e : 00
00000f : cc

Reading...
FAIL. Read wrong data.
Expected c3, read 00. Latency counters: write_1x=080000, write_2x=080000, read_1x=000001, read_2x=000000

In both cases the tools aren't reporting any timing issues but I am wary of the following:

- there is a O_psram_ck_n signal at the top level that is not driven, is an inverted signal magically applied here
- there are no timing constraints being applied to any of the phoney pins to the memory so there could be all manner of delays there

On the inverted clock, I've tried adding another ODDR with inverted signals and routing that through but that didn't seem to make a difference. Removing the O_psram_ck_n signal at the top level does stop the whole thing working at any speed but that might just stop the tools inferring the link to the on-die chip.

I'm now looking at the controller logic itself. Suspiciously the test is reporting 1/2 the writes as being 2x at 81MHz which just doesn't seem right...

Without a good test bench I'm just groping around in the dark, I'm not sure I've got the emotional strength to make a model of the PSRAM itself...

[dominicbeesley]

Two more things to report back.

1) I may have been unfair on Gowin's speed...

It turns out that in default trim (and when reloading older projects) the optimisations all get turned off and the timing model is set to the worst case

Adding

Code: Select all

set_operating_conditions -grade c -model fast -speed 6

to the sdc and setting the pnr optimisations on improves matters considerably but I'm still not quite hitting 128MHz in my original MAX 10 design. But that could be further user-error on the timing constraints!

2) The PSRAM thing is really odd!

In the datasheet for the PSRAM (https://www.mouser.co.uk/datasheet/2/94 ... 760391.pdf) it is stated that for writes one must check for RWDS high at the start of a transaction and insert extra (2x) latency if it is asserted.

However, the original test code checked at cycle 5 and doesn't work at >96MHz. In desperation I turned that off altogether and always do writes with 1x latency...and it works. This shouldn't work but it does...I'm pretty sure it's not correct data left from a previous pass as I've asserted reset for a good 30s (which should corrupt memory) and it passes. Obeying rwds at cycle 2/3/4 fails pretty spectacularly with lots of zeros written to ram where there shouldn't be and some "correct" but misplaced data at others, which would indicate that either the PSRAM is not acting as per spec or there is some other bug in the controller....I need a drink!

Here's a pass of it working at 96MHz...

Code: Select all

Writing...
000000 : c3
000001 : c2
000002 : c1
000003 : c0
000004 : c7
000005 : c6
000006 : c5
000007 : c4
000008 : cb
000009 : ca
00000a : c9
00000b : c8
00000c : cf
00000d : ce
00000e : cd
00000f : cc

Reading...
All done successfully.
Latency counters: write_1x=400000, write_2x=000000, read_1x=3ff588, read_2x=000a78

D

[hoglet]

Two more things to report back.

I'm following this with great interest.

Do the Gowin tools handle mixed Verilog and VHDL designs?

[dominicbeesley]

Good question.... which I'll try and answer before the end of the weekend. If I can get this psram controller working satisfactorily I'll try a BeebFpga mashup which will be verilog plus vhdl.

I think I might have a handle on what's up with the controller but I might not get a chance to try it out until Monday...

[a1exh]

I wrote a tool to convert VHDL into (System) Verilog. So if you every get any tools that don't do Mixed HDL I can convert the VHDL for you.

It uses Verilog wherever it can and only uses System Verilog on things like enumerated types, records, multi-dimensional arrays in ports, some generates. You can convert to 100% Verilog 2k but it can affect readability depending on the VHDL.

After conversion it runs SymbiYoSys to formally prove it's still identical.

[dominicbeesley]

a1exh, Cool, is that an open-source thing or a work thing.

Dave, It looks to me (looking at options, though I've not yet had a chance to prove) like both Gowin and Efinix tools support mixed mode working and

Gowin support Verilog 95, 2001, system verilog 2017 and vhdl 1993 or 2008
Efinix supports Verilog 95, 2k, System verilog 2005, 2009 and VHDL 1993 or 2008

I've not worked out if it is possible to change the flavours of vhdl/verilog on a per-file basis

I think I've now solved my memory "problem", at least I've got 2x write cycles working. I'd been working on the assumption that both ODDR and IDDR primitives delayed their output by 2 cycles but in fact ODDR delays it by 3. Because of that when working at 3 cycle latency the picking up of the RWDS signal was very marginal and not running at higher clock rates. This is a clear case of RTFM...

I just got rid of the IDDR buffer for RWDS as it doesn't seem to be necessary. This seems to work fine at 96MHz, I may try some faster speeds later.

It leaves two questions, which I will try and chase down:

- PSRAM seems to work fine if I ignore 2x refresh cycles when doing writes
- I have run 96MHz clock at 3 cycle latency which shouldn't work but 3 or 4 both seem to work ok.

Which leads me to where I really want to go with this next - how to properly simulate. If I'd been able to see a waveform I'd have spotted the obvious immediately. There are no simulation tools with either GoWin or Efinix, I am going to try and get ModelSim (Altera version) to use the GoWin libraries and see if that will work - at least in GoWin there seem to be some obvious simulation primitives, hopefully just a case of picking these up? Are there any good open-source/free simulation tools that do mixed vhdl/verilog?

D

D

[hoglet]

Are there any good open-source/free simulation tools that do mixed vhdl/verilog?

I have never managed to find one. That's part of the reason I would like, over time, to migrate some of my designs to Verilog only. i.e. to be able to do more system-level simulation.

A while back I did a one-off partly tool-assisted, partly manual conversion of BeebFPGA to Verilog, so I could try out the Yosys toolchain and the iCE40 parts (on the BlackIce/BlackIce II dev boards which Ken Boak kindly donated). That was pretty successful:
https://github.com/hoglet67/Ice40Beeb
https://nanode0000.wordpress.com/2017/0 ... -a-hammer/
In that project I was able to simulate the complete boot of the model B (using Icarus Verilog)

But the upstream mostly VHDL project has now moved on considerable, so this is now somewhat orfanned.

I wrote a tool to convert VHDL into (System) Verilog. So if you every get any tools that don't do Mixed HDL I can convert the VHDL for you.

Alex, if your VHDL to Verilog tool were available, I would certainly try it out. Unfortunately, I don't think Xilinx ISE support System Verilog.

Dave

[a1exh]

It's owned by my employers. But I'm happy to convert anything you like. As long as it's a day I'm in the office I can do it in a few seconds.

I've not used ISE for Synthesis for a long time so I can't comment, we switched to Synplify for Synthesis and ISE for PnR

[leendert]

Thank you Dave for making a nano 9k tree for the Atom. I’m a beginner on fpga and your code is very helpful in my uphill battle. So: owe you one!

Br,
Leendert

[hoglet]

Thank you Dave for making a nano 9k tree for the Atom. I’m a beginner on fpga and your code is very helpful in my uphill battle. So: owe you one!

This was a bit of an exercise for me in getting familiar with the Gowin FPGA tool chain. I have no idea if it actually works, as I don't yet have a Tang Nano board. That's especially true of the new HDMI code. I expect to receive a board in the next week.

The Tang Nano 9K build of Atom FPGA doesn't include AtoMMC support, because that take a lot of resources. Instead it uses the much older SDDOS2 file system plus the SDDOS2 build of the Atom Software Archive. This likely hasn't been tested in quite a few years, so I guess we'll see if it's suffered bit-rot.

It's just possible we could squeeze AtoMMC into the Gowin FPGA at the expense of a few other things, like the SID. Alternatively, it might be possible to use a Pico as an external AtoMMC implementation. There would be no issue with level shifting, as both are 3.3V parts. There is enough I/Os to do this I think.

Dave

[leendert]

Thx Dave,

I’m currently playing with it. It compiles now and uploads code. Will spend a few hours and share my experience. It’s just for fun, SID never had my love, so trading that in for the mmc would have my pref.
I’ll keep you posted, I made a huge step forward with your work.

Br,
Leendert

[leendert]

Hi Dave,

Played with the stuff. I'm getting a rock solid HDMI frame. But no Acorn Atom on top op the screen. Just a screen full of @. Put the scope on the ROM address and dataline, fine looking data is comming out. Looks like the #8000-81FF is not updated by the CPU or read as zero by the 6847.
As already indicated: i'm a beginner on FPGA, could not find a quick fix for it. Also the warnings during the compile: for me as a programmer, some looks a bit nasty, but maybe they are not.

So far...

BR,
Leendert

[hoglet]

Played with the stuff. I'm getting a rock solid HDMI frame. But no Acorn Atom on top op the screen. Just a screen full of @. Put the scope on the ROM address and dataline, fine looking data is comming out. Looks like the #8000-81FF is not updated by the CPU or read as zero by the 6847.

I've done a bit of simulation (with GHDL), and there were definitely some issues with the Video RAM, where I had messed up some of the input values to the dual port RAM block. I have fixed this now and pushed this change back to github.

However even after fixing this error, it's not working quite as I would expect. But this could just be an issue with the simulation, so I would be interested if the fix changes anything for you on the real hardware.

But probably you'll have to be patient and wait for me to debug this once I have the real hardware. Hopefully I'll get a board later this week.

Dave

[leendert]

Hi Dave,

The updates you made results in a perfect starting up, including the + SDDOS indication... Thanks for all the work you are doing...

BR,
Leendert

[hoglet]

The updates you made results in a perfect starting up, including the + SDDOS indication... Thanks for all the work you are doing...

Have you managed to try it with a real SD Card yet?

SDDOS doesn't use a file system. Instead, you need to write the raw image to the SD Card. On Linux this can be done with the dd command. On windows, the best tool I have found is Win32DiskImager.

The raw SDDOS2 image for the Atom Software Archive is here:
- V11
- V12

I would try V11 first, as I think there are issues with the SDDOS build in V12 (due to the 1024 disk limit being exceeded)

Maybe you could post a couple of photos?

I'm still waiting for my board....but at least the tracking is now saying it's in the UK.

Dave

[leendert]

Hi Dave,

Here some picts of the Tang Nano in Atomic mode.

IMG_1268.jpg

Have some issues with the keyboard, so although I loaded the V11, I'm not able to do some input.

I connected a PS/2 keyboard to the PS/2 PMOD and connected data and clock to the according pins 25 and 26. Upon Power on, I see the 3 leds on the keyboard with a short flash and with the scope I see data coming out of Data and Clock, when typing at a key.

Leendert