lopalma.github.io

Holiday summary

I did some... "evolutive engineering", if so we want to call it (jumping from idea to idea very fast), true.
PMS-32 was the latest "cool" idea I had, which I of course could not refrain from engineering in way too much detail for what it got. The two-week pause during the holidays was beneficial. Whenever I got a new idea to pursue I simply couldn't pursue it, giving me more time to ponder. Here is what went on in the last three weeks.

The side-quest: making a tiny softcore

As the heading implies, I've been trying to cook a tiny CPU. That's how miniSPU was born. I fully and thoroughly implemented it, formally verified it... everything. It's a single ~300 lines long SystemVerilog file, the work of just a couple of afternoons. It took up 238LUTs exactly. I was very satisfied, but then I compared it with the existing competition:

My core was, predictably, both larger and not perceptibly faster - a truly inspired combination. It only had four registers, meaning the generated code from an eventually ported C compiler would have been very inefficient; also, although the core itself was a dual issue VLIW parallel core, the most useful instructions (load/store with auto increment/decrement) simply couldn't be paired together. It was also extremely constrained in terms of the instructions themselves: I had managed to fit two parallel instructions in a single 8bit bundle. The CPU could only add, subtract, load, store and jump if less or equal. In general, the performance advantage of a 16bit parallel core was totally rendered useless by the poor quality of C code and the lack of competitivity in size, as it was double SERV.

TEC30: my first massive win

Before committing to actually porting ANY compiler to miniSPU, I wanted to test a new idea and check how much cheaper it could have been in terms of LUTs.
Introducing, TEC30 (Tiny Embeddable Controller, originally Tiny Educational Computer). TEC30 was created by me as an example of a CPU with a very simple datapath to hopefully help a friend of mine understand CPUs better. It turned out to be very small in LUT size. TEC30 is a zero register, memory-memory machine. It means that every instruction takes some data at some addresses and puts it back somewhere in memory, without storing it in registers. The ALU and datapath are 8bit wide (hence the 3 in 30: 2^3=8, whereas the 0 means Zero-registers) but since you can just perform ADC instructions on contiguous bytes in memory, you can perform abritrary size maths, as long as it's just integer calculations. Memory is addressed in 16bits, but to avoid every instruction needing to store 6bytes of operand addresses (dest, src1 and src2) I decided to make arithmetic implicitly target the 0-page, aka the first 256bytes in memory. This way I could halve the size of operands. Every instruction is 4bytes long, composed of an opcode byte, a dest byte, and then two "wildcard" bytes. They can be:

TEC30 is now EXTREMELY C-friendly: ample scratchpad memory (0-page), arbitrary size arithmetic (I can manage all C types). And on top of all that, the TEC30 core fits in exactly 98LUTs.
Exactly: that's PicoBlaze territory in terms of size, except you don't need to sell your sanity to write code for it, though you loose some performance because BRAM reads are synchronous on FPGA fabric. But in turn, if I implement C for this, you get to actually write in C. Totally insane to think about, for me.

If I ever get to port LLVM, writing an operating system would become so much simpler! I'd need assembly only for some critical parts. Before I spend any amount of effort trying to port C, which seems kind of a big task, I'll proceed testing TEC30, will formally verify it, and try to be as sure as mathematically possible that TEC30 works.

Where can I try TEC30?

Unfortunately you still can't, for the following reasons:

What's next