P8X32A Emulation on Tang20K FPGA
ti85
Posts: 44
in Propeller 1
I came across a newer, low-cost FPGA called the Tang20K. I'm wondering if anyone has experience with it and the feasibility of running P8X32A emulation on this platform. Parallax has provided the Verilog files, but I'm unfamiliar with Verilog or hardware coding in general.
My question is: what steps would be necessary to get the Propeller 1 running on the Tang20K (if possible at all)? I'm interested in pursuing this because I'd like to explore options for increasing the Propeller 1's processing power, such as expanding hub RAM or adding more cogs.
Comments
parts look ok, but google finds this
https://www.reddit.com/r/GowinFPGA/comments/zvkswc/tang_nano_20k_announced/
Nice board, with MS5351 clock generator. (unsure how they configure that ?)
and this
https://github.com/juj/gowin_flipflop_drainer
suggests GOWIN FPGAs may not be able to cope with too many clocked registers - node changes ? (too much supply bounce ?)
A MCU design like P1, should have a low change-node count, but it suggests having another platform you know is good would be useful here.
I had been looking for low cost FPGA boards for a while now. During covid they seemed to have vanished. It is great, that there are now these possibilities. So I have bought Tang Nano20k now and am trying to learn....
It would be interesting to know the number of lut4 needed for a full P1? Or an estimation?
Christof
Ah, found it: 9500 LUT6 for P8X32A: https://github.com/jimbrake/cpu_soft_cores
So it looks possible with 8 cores and plenty of RAM.
Once got P1V working on Xyloni
https://forums.parallax.com/discussion/174191/p1v-on-xyloni-trion-t8-fpga
Main problem seemed to be getting clock to higher freq.
I've actually been trying to port to this fpga and currently stuck. I've got it compiling but nothing runs yet. Fmax tops out in the high 70s but there's plenty of room left in the part. Currently compiling the Nth test run as i write this post.
I'm at the stage of wanting to include my own booter for testing but not quite being capable of accomplishing that. The P1 is a beautiful processor but the Verilog is very dense. Still, happy to have what we have. I missed the bus back in the day so trying to catch up with what's already been done (quite a lot !!) I need to get a stable fmax of 64mhz but would love to get that 80 mhz, I just don't see it happening. My last compile utilization
9 gowin_pll/your_instance_name/rpll_inst/CLKOUT.default_gen_clk 40.179(MHz) 291.477(MHz) 6 TOP
10 gowin_pll/your_instance_name/rpll_inst/CLKOUTD.default_gen_clk 20.089(MHz) 77.305(MHz) 16 TOP
Resource Usage Utilizatio
Logic 15469(13687 LUT, 1782 ALU) / 20736 75%
Register 5250 / 15750 34%
--Register as Latch 0 / 15750 0%
--Register as FF 5250 / 15750 34%~~~~
BSRAM 40 / 46 87%
Resource
Resource Usage Summary
Resource Usage
I/O Port 41
I/O Buf 40
OBUF 8
IOBUF 32
Register 5250
DFF 41
DFFE 3877
DFFSE 40
DFFR 73
DFFRE 1192
DFFPE 1
DFFCE 26
LUT 13668
LUT2 640
LUT3 5289
LUT4 7739
ALU 1782
ALU 1782
INV 19
INV 19
BSRAM 40
SP 14
SDPB 26
CLOCK 2
OSC 1
rPLL 1
Tool Version V1.9.9.01 (64-bit)
Part Number GW2AR-LV18QN88C8/I7
Device GW2AR-18
Sounds like what happened when I tried to port P1v to IceStorm. I have a hunch that it is a sign extension issue. That was a problem with the P2 rev A silicon. The same Verilog works fine in Verilator. Go figure. The P1v was originally SystemVerilog, but I had to use a version ported to Verilog 2001 for IceStorm. That was in 2017, so it could be fixed now.
I did some work to pre-load the program into the RAM blocks. That could eliminate problems related to the IO pins and serial port.
https://github.com/SaucySoliton/P1V/commit/44e26fb5efbf85c70bb875ccb3eac1e802a68a22 Also it just makes sense to have the program pre-loaded after the FPGA bitstream is loaded.
I think i have the verilog working on the tang nano 20k. Need a serious code cleanup and then to backtrack and see if i can get the first attempt working. I was able to identify in propeller tool and load / run the cogtest. I'd need to look at some better tests to verify things are actually working. For the 4 cog i was able to compile @ 78ish, now waiting to see what the 8 cog compiles to. The built in LA is really helpful, the tang nano 20k is a pretty cool board. If you were willing to go to a 4 cog / no font rom you might be able to fit in the tang nano 9k. Pretty cool development package and finally something within my budget. I've been wanting to play with the P1V since it's release but couldn't justify it at the time.
@cheezus
That is awesome...are you planning on releasing your finished files on github or on the forums here? I just ordered my tang nano 20K
I'm more than willing to post what i've got here! This port is based on Rayman's release, great source as always... It's pretty straightforward, although it's still very much a work in progress. I have the PLL making a 58mhz PLLx16 clock from the onboard OSC. I would love to leave it at 80mhz and try to see what breaks but without all my test equipment it would be difficult. I did comment all the portB stuffs out. The compiler is real dumb and didn't want to compile with it iirc.
Most of my compilations remove the video generator since I won't be using it. I have wondered what it would take to get the HDMI port working using the video generator? I'm sure someone much smarter than I could make short work of that. With the video in, it takes forever to compile and the video paths are the first ones to fail. It also really beats down the fmax, can't seem to break the 60s with videogen and 8 cogs.
What would be really nice is to get the source for the BL616 chip (the usb interface) and use it to program the P1V but without access to dtr/rts I'm kinda at a loss... I have an M0S board that i was playing with but couldn't quite figure it out. I only spent a few days and i may revisit at some point.
I HAVE decided i really do not like the Gowin tools, the complier output is very basic and error messages can sometimes be non-existent. I guess that's why these parts are dirt cheap and others are not. There's probably all kinds of edge cases where this thing breaks but, hey isn't that part of the fun?