I finally implemented an ISA design I came up with over a decade ago, hereby dubbed `Tugman.`

The current proof-of-concept is an 18-bit implementation running at up to 50MHz (all instructions execute in 1 cycle) with 8K-word memory, on a Tang Nano 9K. (On Xilinx or Tang Nano 20K it should work at 100MHz+). The entire SOC with a UART and IO decoding takes up 6% of FPGA resources (~500 LUTS, ~120 flops, 9 BRAMs)

New: on Tang Nano 20K, stable at 111MHz.

https://tildegit.org/potato/Tugman

The CPU is a stack machine with a VLIW-like instruction set based loosely around a J1, but with a more complex ALU, with direct operations on NOS, memory, IO, or top of return stack.

The instruction set is quirky, as each instruction can simultaneously do an ALU operation, issue a memory read, adjust stack pointers, and issue a write to memory, IO, or stacks, or return from a subroutine. Jumps and calls may be conditional on Z and C flags. This makes coding interesting.

Here is a quick summary of the instruction layout:

Unlike every other minimalistic stack machine I've ever worked with, coding it in assembly is actually fun, and the instruction density seems to be really good.

Some highlights:
* Single-cycle execution, 0-cycle return in most cases;
* Instruction density competing with register machines;
* A reasonably complete instruction set;
* 1-cycle interrupt latency (not yet implemented, but may be trivial);
* 1-cycle per memory indirection, as deep as you need;
* All calls and jumps can optionally drop;
* All logical operators can clear, set or keep the carry flag unchanged;
* Forth in hardware;
* Co-routines
̶*̶ ̶P̶r̶e̶d̶i̶c̶a̶t̶e̶d̶ ̶c̶a̶l̶l̶s̶
* Other weird stuff (TBD)

The repo contains a proof-of-concept system with a UART (115200kbaud), a loader, and a simple monitor.

A simple FASMG-based assembler is in the repo.

[This top entry is edited to be up-to-date. The rest of the thread follows my development effort over time]

Interesting! (And welcome back) and thanks for sharing your repo - I see you have some details of your assembly language too.

Last night I managed to improve fMax to 45MHz and reduce utilization substantially, while adding a ton of possible instructions. The trick was to eliminate the explicit subtraction, and instead introduce a bit to invert TOS into the ALU (and invert the carry input). Subtraction is now synthesiszed as NOT_TOS + ALU_B with carry making the NOT into proper 2's compliment negate.

Negating TOS is actually very useful, since literals are only 17 bits (a pre-negate on ALU_A saves an explicit negation instruction). And it's very useful for masking bits for logic operations.

I also switched the 8 operations into two sets of 4 operations: one set uses ALU_A and ALU_B inputs, while the other, only ALU_B (currently, B passthrough and shift right), and removed rotate left (which can almost be replaced by TOS + TOS with carry).

The core is now 20% smaller than the stock J1 CPU, but infinitely more usable and fun. It is 25% slower theoretically, but I'd say the instruction density is close to double.

Copying Memory

memcpy is always a pain with a stack machine: incrementing two pointers and keeping a count... Currently, a 7-cycle loop is the best I can do. It's not bad, actually. I keep wanting to add autoincrement, but it's probably an unnecessary expense for a processor with an 8K memory space.
[Note: later I present a 6-cycle memory copy loop!]


This takes advantage of the fact that reads are issued on ALU_B (TOR, TopOfRstack), while it's being increment in the ALU, and the result is written back, in a single instruction. The read result is available next cycle, while RSP is adjusted so that TOR is now source address. Next instruction stores memory, and the following, increments TOR. Finally, we decrement the count (while adjust RSP back to destination), and loop while not zero.

Looking at it today, I think I can hoist the lit 1 out of the loop and take it down to 6 cycles!

Kind of cool, actually.

Very cool. It is small enough that many cores could fit in a larger FPGA.
Have you seen the 4-stack CPU?

It is tiny, and can be configured to run off a single BRAM with 1K words. This makes it a great picocontroller in a bigger system - an IO, disk, or communications controller, or a video subsystem.

I've admired Bernd's CPU from afar. It seems like a nightmare to program though -- too many things to keep track of. Para mi, Tugman processor is at the limit of pleasant.

Today I added CMP and TST. These affect flags and drop, which is usually what is necessary; I hated what my monitor code looked like without these!

I dreaded adding the extra logic, but amazingly, it didn't affect size and actually improved fMax by 1MHz. Weird, but whatever. It almost makes sense because LUTs have 4 inputs and I was using two in a couple of places, but speed improvement is harder to explain -- mostly luck I suppose.

After some consideration decided that conditional calls are not really worth it, and I'd rather have a call, a jump, and six other conditional jumps.

This and a couple of other small changes reduced utilization back to 460 LUTs and improved fMax to 49.192 MHz.

Spent the day working on a monitor and reviewing hardware. Other than fMax dropping horribly as soon as I touch the IP mux... I am stuck with call, jump, jz, jnz, and jc -- as soon as I add jnc I lose 5MHz and gain layers of logic. I tried separating the condition code mux, but it's even worse... Left it alone, as I like 49.195Mhz max, for now. Someday I'll have to figure out how to add timing constraints, or pin down some components with location constraints.

I also figured out a way to sneak extra instructions in -- for instructions that don't affect the carry flag normally, like loading portB into TOS, I can do complicated tests and set the carry -- without any extra opcodes!

I was writing an ASCII-HEX routine, and range checking was a pain. I put in an instruction that does a range check on NOS against high and low bytes in TOS. That worked fine, but added 50 LUTs and slowed down the system by 8MHz... Then I took it out and rewrote the converter without it, and it was only 4 instructions longer... Completely not worth it!

But I will keep this in mind for later.

I now have a hex dump and hex input, will write a monitor tomorrow.

I just realized that memory locations 1 and 3FFFF may be used as scrap registers with almost no overhead.

The ISA allows for 1 and -1 to be used as ALU_B constants, and since there is a memory read on ALU_B every cycle, memory locations 1 and 3FFFF, next cycle may be used to read the memory into ALU_B. For writing, just WMEM bit stores TOS into 1 or -1 when ALU_B is B_1 or B_N1.

Looks like a nice machine. Block ram makes big difference for many designs.

BRAMS are dog**** slow on this device! I am used to old Xilinx XC3S which is at least twice as fast. I think it's 5-6 ns before the BRAM responds after the clock. I should really move to the $30 Nano20K device which should be almost Xilinx speed.

Speaking of BRAM, my 18 x 8192 RAM synthesizes as 9 2-bit BRAMS instead of the expected 8 18-bit ones, which is sensible as it avoids muxing multiple devices. I made a feeble attempt to build with a single 18-bit BRAM, but it wouldn't synthesize, insisting that I was making a read-before-write memory, which I clearly wasn't. I will have to try again later, for now it's 8K words.

Although I am almost happy with the ISA, every time I try to finish the monitor I get annoyed with the details. My attempt at the Z and C flags along with test and compare instructions that do not modify TOS but just set flags seemed clumsy, and I still found simple things like returning from a subroutine with some kind of a flag hard to implement without a inflating and slowing down the CPU (for some reason, just keeping flags in registers is a lot more expensive than pushing them onto the return stack with the return address and restoring them, even though it is a lot more verilog to do that!).

So I took an extra bit in jump instructions for an optional drop, and removed test and compare instructions. For compares, I can subtract and jc/drop or je/drop, flags are no longer restored on return. je/jne tests tos as it exists, so it's easy to pass flags around and drop them during the test in a single instruction. I can add js/jns for testing the sign bit, but it costs a little and I haven't needed it yet.

Unfortunately I am out of bits in the jump/call instruction, so I had to switch to relative branches with a 4K reach (or just limit the RAM to 4k)... I could keep unconditional jumps to full 8K and just limit the conditional branches to 4K, but that would require another decoder and a bigger IP mux, and with this software you never know if it will make it much bigger or much smaller and faster until you try.

Keeping the flags separate across calls/returns bloated me to 500 LUTs, but I am just over 50Mhz now.

Amazingly, there were almost no changes in the assembler and the software.

Not using flags might be a better option, if you look at something like fig-forth. 0branch and branch and forth calls/returns are the only program counter operations.
Most of the older computers used Skip on condition and Jump and that kept them simple.
When I was playing with the other brand of FPGA's, the design would often compile but not run in the hardware.
I don't care about fmax, more about are the setup and hold times met. The software never could tell me.
I have gone to CPLDs that I can design with. (Wincupl) and the programmer was on sale.https://store.rosco-m68k.com/products/l ... programmer

I think the FPGA software automatically adjusts the timing of internal logic to meet setup and hold times. If it cannot it gives a warning. I believe one can also specify what the delay (-min for setup and -max for hold) needs to be for IO signals. One can even specify the I/O standard (voltage levels and timing). There are all kinds of stuff that can be specified in constraint files. It is a bit of a learning curve though.

I am very happy with how it's turned out (except that I lost a bit of jump range): it's mostly Forth-like, but carry flag is still there if you want it, and you can drop or not while jumping. Z branches just test TOS, C is flopped from last ALU result.