Bit Serial RISC-V

[Antti Lukats]

Hi,

only 60 hours to go, I am eager to see if Olof submits his bit-serial RISC-V !

It was running single threaded Zephyr a few days ago.

I have made some bit-serial trials too, but well my bit-serial ALU alone for Kortex-S (thumb2) 

https://github.com/AnttiLukats/Kortex-S

already consumes 126 LUT on Xilinx, while the complete RISC-V SoC is about 196 LUT6

nanoSparc could probably beat that, but I did not find the source archive, to many HDD's ago..

back to final tasks, Zephyr running in many terminals 24/7 :)

g

Antti

[Olof Kindgren]

In terms of functionality, not much has happened. It's still lacking interrupts and programs have to be preloaded to RAM. I could perhaps find time to do an attempt at a primitive implementation of the HW support for interrupts, but realistically I can only borrow a couple of hours from the family. And judging from the coughing coming from the youngest kid, I don't expect expect much time to work on this (or sleep!) at all the coming days. And it would still leave me with figuring out the sw side.

So I have instead focused on bringing down the size of the CPU itself, mostly for fun. It's currently clocking in at 461 LUTs. Some parts have been hand-optimized with a ton of Karnaugh maps, while other parts are in a great need to be rewritten so there is still some room to bring this number down with some more work.

It's not a very good CPU, but I think it has some use. Since it's not using any RAM for microcode it could be potentially useful in applications where on-chip RAM is a scarce resource (e.g. as a control plane CPU in a data capturing/streaming application)

There is also a reasonably clear separation between control logic and data path, so it would be fun to make it configurable for different bit widths to see the area/speed trade offs. At least 1,2 and 4 bits would be fun to explore. Any higher and I don't think it makes any sense against an architecture purpose-built for 8/16/32.

Still super interested to see what kind of design choices everyone else has made, and of course a bit sad that I won't make the deadline. But it's ok. Failure is always an option :)

[Antti Lukats]

On Saturday, 24 November 2018 22:36:13 UTC+1, Olof Kindgren wrote:

In terms of functionality, not much has happened. It's still lacking interrupts and programs have to be preloaded to RAM. I could perhaps find time to do an attempt at a primitive implementation of the HW support for interrupts, but realistically I can only borrow a couple of hours from the family. And judging from the coughing coming from the youngest kid, I don't expect expect much time to work on this (or sleep!) at all the coming days. And it would still leave me with figuring out the sw side.

wau, take a sleep(as_much_as_needed); 

preloaded on ice40UP ? You mean you actually use multiboot reconfiguration to load SPRAM and reconfigure from next bitstream with "pre initialized" SPRAM content?

I have been to stressed to figureout/recall this option :( 

I think I used it or planned to use on first work done iCE65 family but it was too long ago

 

So I have instead focused on bringing down the size of the CPU itself, mostly for fun. It's currently clocking in at 461 LUTs. Some parts have been hand-optimized with a ton of Karnaugh maps, while other parts are in a great need to be rewritten so there is still some room to bring this number down with some more work.

It's not a very good CPU, but I think it has some use. Since it's not using any RAM for microcode it could be potentially useful in applications where on-chip RAM is a scarce resource (e.g. as a control plane CPU in a data capturing/streaming application)

there could be some use case you cant even know yet.

running from rad-hard tolerant FRAM in space? maybe :)

 

There is also a reasonably clear separation between control logic and data path, so it would be fun to make it configurable for different bit widths to see the area/speed trade offs. At least 1,2 and 4 bits would be fun to explore. Any higher and I don't think it makes any sense against an architecture purpose-built for 8/16/32.

bit serial actually needs bit serial ISA to be really efficient, to pre-tune the ISA to allow on the fly binray tree instruction decoding during bit shift of instruction from serial memory stream like SPI XiP

implementing existing 8/16/32 bit ISA in bitserial fashion is much harder and result not as good

 

Still super interested to see what kind of design choices everyone else has made, and of course a bit sad that I won't make the deadline. But it's ok. Failure is always an option :)

Olof,

for heavens sake, you have not failed. 

You made WORKING bit serial RISC-V implementation that actually runs an RTOS! This is cool.

I have given up all my attempts to make some useful bitserial engine, you did not and succeeded with usable result!

But yes, saying no and stepping out is an option to take sometimes.

In my opinion forcing bit serial RISC-V to successfully run multi-threading Zephyr to be counted as valid contest entry is pretty hard and kinda nonsense requirement.

g

Antti