Hello friends. Long time (lost my password). Hope everyone is well.

I've spent the last n days setting up and debugging yosys/apycula open-source toolchain, which is not bad these days and supports Gowin chips.

Nano 9K, at $20, is pretty amazing: a reasonably-sized FPGA (a minimal system with Arlet's core is 10% utilization), 48KB of block RAMs, 64Kbit SDRAM, lots of flash, USB for power, configuration and serial, SD card, HDMI hardware and an LCD connector. And a bunch of IO pins, 6 LEDs and 2 buttons.

On the negative side, Gowin FPGAs are on par with cheaper Lattice parts, and I miss the features of even low-end Xilinx chips, such as the up-to-16-bit SRL16 shift-register directly in a single LUT...

Anyway, I think this is the best deal this century for FPGA hobbyists. There is also the $10 Nano1K, which is probably too small for anything interesting, a $15 Nano4K with a hard ARM cell on the FPGA, and the $30 Nano20K which has a faster/bigger FPGA...

As mentioned, I managed to hack up a quick-and-dirty 6502 system to flash an LED, running at stock 27MHz. The Gowin toolchain takes about 1 minute, the free toolchain around 30 seconds to build it. Almost reasonable (I was building small Xilinx systems in 10-15 seconds, but that was after a year of fiddling with the makefile, so I am still hopeful about yosys).

The board is big enough to support pretty much any 6502 system, I think. I'll see if I can make a CHOCHI work-alike and get forth and BASIC up to start with.
...
Link to repo with my 6502 experiments:
https://tildegit.org/stack/Tangnano9K-65c02-experiments

Ah - welcome back! Indeed, the gowin FPGAs and the tang boards are very attractive, in principle. Cheap, available, open source toolchain. The 20k is, I think, the one I had my eye on.

Great to hear you got started with it and got a nice result!

To be fair, I was warned of poor construction quality (scroll down here: https://github.com/YosysHQ/apicula/issues/262) and flakiness, but I haven't experienced any yet personally.

Interesting stuff - I have one of these units that I was looking at for another project (RISC-V) so good to know you can get it going with open source stuff, although I did have some luck with the GoWin tools under Linux - their license key is easy to get but only lasts a year - no idea why they even bother, but hey ho...

I struggled to get the RAM plumbed into the RISC-V core with the IO I was after but as I have no previous FPGA experience, I was not surprised and ran out of time & energy at the time (about a year or so back) to carry on.

Have you a write-up of what you did with it?

Thanks,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Gordon - I am still struggling with it, but am happy to write the things I learn. It's always a bit of a struggle -- in this case I stared and rebuilt over and over a simple harness for Arlet's core until I came across a post here, suggesting holding RESET high for 7-cycles on power-up.

So I got the yosys workflow down, more or less, and am trying to clean up and create modules for simple things like memories and UARTs. I'll post a link to my repo when it's a bit more palatable.

Great, thanks.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Heh. For the 65c02 core (Arlet-based) to start, the reset has to be asserted for 1 cycle. Makes the reset circuit much simpler.

I am keeping my work-in-progress stuff in https://tildegit.org/stack/Tangnano9K-65c02-experiments

Currently using the 6 leds to display the contents of a counter which the 6502 software increments about every 1/2 seconds.

So I thought I would rip out a UART from some other project, and it would take me, what, maybe an hour or two to wire it up to the processor... Sounds familiar, right?

My CHOCHI uart was actually from PicoBlaze, and is designed for the Xilinx FPGAs. There are a few 'example' projects with UARTs, but there are all kind of screwey - one is translated from some kind of Python so it's a pile of wires and logic that is almost impossible to separate the UART from the rest of the junk. Then there are the 'examples' that look like they were written by ChatGPT (or first year engineering student who just passed Verilog 101 course)-- pages of state machines even on the trivial transmit side. Just disgusting to look at! I just couldn't stand the UART to be bigger than the CPU...

So I spent the last two days writing a simple UART transmitter -- a counter and a little logic to get and push bits out. Of course, most of the time my serial terminal decided to show garbage for reason unknown (possibly from injesting junk and going into 'screw you' mode), and nothing at all worked. Finally today, on the second day of headbanging, I found the magic sequence of restoring the terminal.

Then there was the idiocy of the toolchain generating non-working circuits when you misspell a wire name. Why not fail -- clearly 'clokc' connected to nothing will not drive the FPGA...

Then there was the idiocy of the FPGA pretending to configure from RAM but silently reverting to its flash configuration when the bitstream failed, leading me to think everything is fine long after doing something stupid.

I finally got an ironclad workflow where I change things enough to know I am on a new bitstream, reset the terminal, parse the megabyte of synthesis and place/route logs for errors, and configure, certain that it is in fact a new configuration. What a terrible pain!

But I think I have a nice and compact UART tx circuit working. It should take me like an hour to connect it to the CPU tomorrow.

Not familiar with your toolchain, but does it have TTL library? serial transmitter is basically a parallel-in serial out 74165 shift register with some circuitry in the front end to handle the start bit. For even simpler transmitter, you can just have a flip flop and bit-bang it.
Bill

Plasmo: interesting, I totally forgot about the TTL-verilog library... I am sure the libre yosys has that.

The transmitter I settled on is just a decade counter that stops at the top until reset, and I have a 10-bit buffer with a start (0), 8 bits of data, and stop (1) bits (the counter stops at bit 9, the stop bit). The 8 data bits obviously can be loaded from the CPU side, and there is a busy flag from the counter.

Theoretically, a counter should be smaller than a shift register on this FPGA (unlike Xilinx with its amazing in-LUT shifters! God I miss those!). Although, maybe not, since each bit has to be a flop anyway, it's just adding an input mux LUT which comes for free... Hmm. Only 3/4 of GOWIN LUTs have flops, but still, that is probably a better approach.

The receiver is a little bit more tricky.

Yeah, I've been in that situation where the new bitstream isn't successfully loaded. Some kind of LED telltale which is different from one build to the next might be one way to verify. It certainly leads to confusion and wasted time if not running the latest design!

Since I am debugging a UART tx, I just have it output a single ASCII character. I started with 'a', and increment every build till I get to 'z' then start over.

A clean shift-register version, with a demo (button press outputs sequential ASCII characters):

UPDATED: tx and rx working

https://tildegit.org/stack/Tangnano9K-UART

OK, got the uart working with a 65c02 core, doing echo and CR translation. Need to implement tx ready status bit, using delays for now.

https://tildegit.org/stack/Tangnano9K-65c02-experiments