Tang Nano 9K - a (n almost) perfect 65(x)xx platform

[enso1]

The UART transmitter, btw, turned out to be really tiny:

Code: Select all

reg [9:0]shifter = 10'b11_1111_1111;
always @(posedge clk) begin
  txout <= shifter[0];
  busy <= ~&shifter[8:0];
  if(load)
    shifter <= {din[7:0], 2'b01};
  else 
    if(shift)
        shifter <= {1'b1, shifter[9:1]};
end

I wound up instantiating shift register differently to save a few slices...

I am a sucker for pre- and post- mature optimization.

[enso1]

Jebus! I spent the whole day connecting the uart and cleaning up stuff (and way too much time trying to figure out why adding an extra wire made the circuit noticeably smaller). Then I pushed the code to the repo, but when I came back later nothing worked! Garbage on the terminal.

I am still trying to figure out what happened.

I think GTKTerm is most of my problem - it gets into a state where it shows garbage, and then I break the circuit and the 6502 software sticking in delays, trying to figure out why I am putting out garbage. A magic combination of sending breaks, resetting the board, reconnecting to the same port, and sometimes quitting and restarting GTKTerm and things work again. It may have something to do with overflowing its scrollback buffer, but I am not yet certain.

Also, there is the silent reversion to the flashed FPGA circuit when the new bitstream is sucky. I really need to flash it with something truly distinctive.

With about a minute build time, there is just enough time to get distracted...

[hoglet]

I'm following this thread with great interest.

What are you using to program the board? I've was able to program it reliably with openFPGAloader. I was also able to modify openFPGAloader to support programming of the user flash.

Dominic Beesley and myself spent a fair bit of time porting the AtomFPGA and BeebFPGA cores to the Tang Nano 9K. It turned out to be very nice board, and the Gowin tools are useable and fast. The hardest thing to get working was the PSRAM.

If you are interested, there are more details here:
- Chinese FPGAs (stardot)
- Atom FPGA on the Tang Nano 9K (github wiki)

Dave

[enso1]

@Hoglet - I do use openFPGALoader (which reports a bad checksum with yosys, but it seems to be just incorrect checksum code, because it does flash the board fine).

I also use yosys/apycula open-source toolchain, which I found about twice as fast and provides many yet untried options such as the possibiliity of hard-macro-like pre-built components -- I am investigating.

It also has a graphic tool to see the innards, like the Xilinx FPGA editor. Haven't explored much.

It dumps the design to json intermediate format, so there is some hope that I could splice designs together or build an instantiation macro-assembler of sorts the way I did on Xilinx...

But yeah, it is a pretty good board. Thanks for the links, I will definitely check out your Atom for clues on how to use PSRAM and other components. What's the access speed of the PSRAM? I'm sure I'll have more questions for you later!

[hoglet]

enso1 wrote:

@Hoglet - I do use openFPGALoader (which reports a bad checksum with yosys, but it seems to be just incorrect checksum code, because it does flash the board fine).

Have you seen this openFPGAloader issue: Tang Nano 9K CRC error with -b tangnano9k

The cause is a bug in Yosys that was fixed just two weeks ago. I think this is the corresponding yosys issue: Tang Nano 9K bad checksum when flashing.

Edit: StackSmith == Enso1 ???

enso1 wrote:

What's the access speed of the PSRAM?

Not nearly fast enough! For random accesses I think we are running with a cycle time of 250ns.

In this respect, the Tang Nano 20K is better: it uses SDRAM which is simpler to interface to, and can be run with a cycle time of 100ns.

enso1 wrote:

I'm sure I'll have more questions for you later!

Good - these board are excellent value and deserve more air time.

Dave

[enso1]

OK, got a 32K RAM (+2K on top) system working solidly, and acting like a Chochi with half the RAM.

Can reset into the bootloader with one of the buttons and load Wozmon over the serial at 115200.

[enso1]

Just for giggles, swapped hoglet's 65c02 (and Big Ed's?) I've been using from the start for the plain Arlet's 6502 core. Surprisingly, the plain core uses a lot more FPGA resources! These things are so unpredictable and this FPGA is a bit odd (only 3 out of 4 LUTs have flops attached, for instance!) -- maybe the more complicated core maps better somehow...

So my little 65C02 system with a UART uses 12% of the FPGA slice resources.

Theoretically, it should fit 8 65c02 cores with 6Kb RAM each, multiplexing the UART of course. That would be a curious device.

So far I haven't been able to up the clock speed from 27MHz. I've been trying to get the PLL working, and for a while had it working at 33MHz (pretty sure it was actually working - I had two LEDs flashing in tandem with different counts matching 27MHz and 33MHz clocks), but then everything went to crap as usual, and the terminal started showing junk and nothing I could do worked, and I wound up backing off to the stable 27MHz.

No other frequencies seemed to work either, so I suspect that most of the time GTKTerm or my PC hardware (or the USB on the FPGA board) chokes and leads me to think nothing works. I also am not sure about the actual frequencies and the correctness of the UART timing loops, something that would take a minute with a scope if I had one here (my lab is far away from where I currently am).

[enso1]

It stops working at 33MHz - manages to print the bootloader prompt but cannot load wozmon via serial port.

Seems to wokr ok at 31.5MHz, but I haven't tested it long enough.

Works stably at 30Mhz, and I will leave it there for now.

That's pretty crappy, considering a lowly 20-year-old Xilinx XC3S50 can solidly run Arlet's core at 100MHz. I suppose it's possible I am doing something stupid with the DI mux... Note that I've made no effort to constrain anything or do anything timing related (and have no clue yet how to do it with this toolchain).

On the other hand, it is much larger, on the order of XC3S500 and has 48KB of block ram, and for a $20 board you still get quite a bit of stuff . So I will try to remain positive and carry on. Even though I desperately miss SRL16 shift registers -- it is just so much easier to build sequencers with almost-free shift-registers!

P.S. I've been told that the $30 Nano 20k is faster. P.P.S. Just looked at the specs - GW2 FPGAs (such as the one in Nano20k) are pretty much exactly twice the speed of GW1 (in Nano 9k).

[enso1]

Rebuilt with Gowin IDE which provides timing reports -- as is,fmax is 32.8MHz, so I was pretty close. There is probably a way to close timing paths to speed things up a bit.

Both Gowin IDE and yosys/apycula take about 44 seconds to build this project, with nearly identical utilization.

[enso1]

With 48K or BRAM, became unstable at 30MHz. I downgraded back to the native crystal speed of 27MHz, which is some kind of a magic number!

[enso1]

So, this FPGA has no dual-ported BRAM capabilities -- I found out trying to implement a J1 CPU (a minimal stack machine which issues simultaneous data and instruction reads using two ports).

Since the BRAMs can run much faster than the rest of the logic on this FPGA, I rigged up a BRAM at twice the CPU clock. Temporarily disabling the data memory (to simplify debugging), I was able to run this double-clocked contraption at 75/150MHz (it seemed to fail at 100/200MHz). Executes code, consumes 8 BRAMS and 3% of LUT logic (!)

Adding the data access requires some finesse (and eats 10% more of LUTs - maybe muxes for the address and data buses?)... I will do this another day.

But double-clocking J1 memory does seems sensible, since it needs an instruction read on one port, and data address is available on the datastack. Data read result is provided to the ALU result mux, so it can come in pretty late. It should work.

I will try it another day.

[hoglet]

enso1 wrote:

So, this FPGA has no dual-ported BRAM capabilities -- I found out trying to implement a J1 CPU (a minimal stack machine which issues simultaneous data and instruction reads using two ports).

On the Tang Nano 9K I've definitely been able to infer dual port BSRAMs with the Gowin tools.

As fas as I understand, there are two different parts that are both referred to as the GW1NR-9:
- the original GW1NR-9 (which doesn't support dual port BSRAMs)
- a newer GW1NR-9C that they then renamed to GW1NR-9 (which does support dual port BSRAMs)

This is really confusing!

In the Gowin project file, make sure the part is specified correctly:

Code: Select all

    <Device name="GW1NR-9C" pn="GW1NR-LV9QN88PC6/I5">gw1nr9c-004</Device>

This is slightly clearer in later revisions of the datasheet:
https://cdn.gowinsemi.com.cn/DS117E.pdf

Quote:

[1] For the GW1NR-9 devices, only the C version supports dual port mode.

The Tang Nano 9K has the 9C version.

Dave

[okwatts]

I purchased one of the Tang Nano9K boards and have been following this thread. I am definitely not one knowledgeable to program these things but have followed the development of other people's work using Altera, as well as the Nano series. I also followed hoglet's post on the AtomFPGA and that works very nicely although using a PS2 (US keyboard) is a bit of an adventure. I note there are references to a BeebFPGA but so far have not seen this implemented yet on the Nano9K (There are 4 other FPGA's on which it is though).
I realize that there are a number of BBC Micro emulations available but would be interested to know if there is any further development for one of the Nano FPGA's (ie 9K or 20K).
Keep up the good work!

[hoglet]

okwatts wrote:

I realize that there are a number of BBC Micro emulations available but would be interested to know if there is any further development for one of the Nano FPGA's (ie 9K or 20K).

Yes indeed there is.

There is a Nano 9K build here:
https://github.com/hoglet67/BeebFpga/tr ... win/tang9k

It uses the same pin assignments as the AtomFPGA build.

The ROMs are stored in external SPI FLASH and are copied into PSRAM on power up.

I do need to create a Wiki page documenting this build, which I probably won't have time to do until next week.

(DominicBeesley did much of this work, especially the PSRAM controller)

Dave

[enso1]

Hoglet: are you sure? I thought I was getting dual-ported BRAMs, but noticed that the reports showed 16 BRAMs instead of 8! There was no complaint from the tools or anything, but the BRAM utilization was doubled for verilog normally resulting in dual-port BRAMs, both with yosys and GOWIN.

The toolchains will silently do stupid things -- if you mis-spell the name of a wire, yosys will just create a non-working circuit and leave you guessing as to why. With the 'dual-port' BRAM being faked by doubling the BRAM, I have no idea how it would actually work -- I think by stealing the second BRAM's write port and writing into both, but offering two separate read ports? Or is that what they call 'pseudo-dual-port'? I find their memory manual pretty confusing.

I also noticed that there is only one option for the 9 series FPGA in the GOWIN toolchain, so I don't think I am wrong about the BRAM doubling.

But please show me I am wrong -- I would absolutely love a dual ported BRAM!