Category: Uncategorized

Hardware State

The 305 CPU core is working very well and reliably in testing so far, I haven’t encountered any major issues since I originally got it working on FPGA (hopefully that was mostly just one-off problems).

Minor issues that can be improved from here are reducing some internal drag to allow for higher speeds and adding more extensions for easy CPU-style management & more optimisation. Customised MCU-like use cases where it launches a fixed program across some number of cores/threads seem to be stable even when pushing near the capacity of some FPGAs by maxing out the core count.

I’ve been testing across a range of cheap FPGAs and at least one model is very reliable with this design (more testing of this design on others will happen eventually).

Software State

The OS software, compilers etc. are still a little barebones but mostly working and ready to start porting to hardware. This may involve splitting parts of the OS into example code for embedded developers, or may involve a new version of the kernel built for my own configurations etc. The integration part isn’t complete yet but things like the filesystem could already be ported to the current soft CPU designs in theory.

Current Offering

I can sell you customised MCU units with customised software if you want (it’s just not well packaged into a complete set yet).

Packaged offerings will probably come later in the year.

I’m very excited about current progress.

Very early multi-core tests are functioning but with limited integration. Early tests show 8 LEDs being activated with reliable timing, each LED controlled by a program running in an individual hardware thread across 2 CPU cores on FPGA.

This means that what is now working is multiple CPU cores with multiple hardware threads per core (building on my work on hardware multithreading in the last updates) and this is working on reasonably small FPGAs with 2 cores & 4 threads per core (8 hardware threads total), but there is no standard interface for interaction between cores & threads yet to run a sensible operating system & start/stop/debug programs after boot.

So by adjusting the configurations in different ways, I should be able to make relatively efficient use of FPGA space (or maybe later custom silicon area) providing a near maximum of multiprocessing throughput to fit any reasonable volume of electronic space. This logic only currently applies to simplistic programs though, it doesn’t have full compute extensions like FPU or MMU for complex software packages at this stage!

Current & Short Term

Current builds reach an fmax of a whopping 10MHz-30MHz depending on options, but the remaining slow part seems to be mostly the ALU output (the rest was probably just my testing I/O).

This means if I’ve got my current assessment right then the design probably currently aligns with typical performance expectations for simple pipelined cores and should be able to be optimised further accordingly, maybe pushing to around 50MHz or higher (this depends on FPGA as well of course).

The extended options do still add additional drag, so there will probably need to be some delicate balance between “add every additional optimisation possible” and “try not to weigh down the design further leading to more complex logic or slower FPGA placements”.

The short term performance goal is to push it above or around 50MHz with more reliability testing and to come up with a plan for faster & more full featured models.

Towards 100+MHz: Two Options

My next real performance goal after making some smaller improvements will be either pushing over 100MHz or reaching equivalent performance some other way e.g.

• Either I keep extending the one main CPU core design and try to make it do everything and have every configuration option for every possible optimisation, convince everyone it’s the best design in the world, get it to run on every single FPGA model, get it manufactured on the latest equipment to push the performance, …
• Or, I market the 305/306 as the main design with efficient multithreading, but just pair it with alternative soft CPUs based on other open-source designs for other performance niches, all supported by the same software

Easy Option For Higher Single-Threaded Performance

Given that I’m largely limited by FPGA performance bounds as much as by my ability to keep simplifying pathways in the design, I think I can probably come up with a faster single-threaded alternative perhaps testing 32-bit/64-bit performance differences to see if I can easily juice higher clock speeds out of a 32-bit design (in theory this should cut out large parts of the slow stuff…).

My hypothesis is that the typical theory on 5-stage/6-stage cores is a leftover from 32-bit cores where maybe the ALU operations were proportionally less slow in relation to other processor mechanisms, whereas for 64-bit designs we probably need to break up the ALU or other internal calculations much more (breaking it into at least 7 stages). But I’m not sure yet, my current issues can probably be optimised away further in 64-bit too.

Peripherals, Performance & Dev Boards

These will be the focus of short term activities, getting useful code meaningfully booting with good I/O. So I expect to have some minimal graphics, storage, input etc. working shortly so I can start testing the OS on the new designs.

For the short term this will mean optimising & extending the hardware/software designs for readily available FPGA boards then working towards a custom FPGA motherboard.

Full OS Support

This will come more gradually but is already underway. The main targets will probably be more stripped-down configurations but I hope to eventually be able to run full operating systems.

For now my OS kernel & C runtime code will be treated as a resource for test components rather than as an immediate boot target (since a simpler OS build would be more suited to some configurations).

Real-Time Reliability

The main target for the current processor design and for simpler builds of the OS will be for timing-sensitive motor control or similar tasks (mostly in the robotics/industrial/embedded field).

Improvements in this regard will move towards having a well tested base “microcontroller” configuration that’s well suited to robotics and that should work on multiple FPGA targets.

Future/Faster Models

There’s not much point developing CPUs if you’re not eventually going to make the fastest CPU ever, so obviously I’m not there yet but I’m actively investigating options for superscalar optimisations and for eventually getting chips manufactured (for now, FPGAs are actually ideal).

Subject to further testing, initial FPGA+LED tests are showing the current models booting and show some promise as becoming fully supported soft CPU models in the near future:

• 305, single-core, single-thread
• 306, single-core, single-thread
• 305, single-core, 4 threads
• 306, single-core, 4 threads

Current Model Naming

305 & 306 refers to the base pipeline. These are based on an open-source 5-stage 64-bit RISC design but with the 306 being extended with an additional maths stage. The 306 therefore is the more full featured but less stable option, the 305 base pipeline is relatively stable and runs okay on FPGA (306 currently has more timing issues, but basically works).

Single-threaded configurations are currently more stable/faster, this can be improved over time though. The main configuration of this design is intended to be 3 threads or 4 threads, configurations with 2 hardware threads or with more than 8 probably won’t be supported (the sweet spot for maximum throughput & efficiency is probably either 1, 3 or 4).

A Word On Consulting

I can offer general services relating to my product range, I don’t want to be a consultancy business though. My ambition is for finished products and my circumstances don’t adapt well to easily attracting clients for one off jobs, I’m stuck out of town for now so it’s easier to just create & export products.

Soft CPUs For FPGA

This will probably be my main product, I know it’s a bit saturated but frankly I don’t really care unless anybody can actually compete with me in bundled extras & quality control. I think I can clean the floor in this category if I put enough work in (not there yet though!).

• The 200/210 architecture will remain as my small in-house design (currently only suited to simple or hobby uses)
• The 305/306+ models will be my larger scale devices, these will be scalable & competitive for typical FPGA uses once I’ve improved them some more (these are based on third party designs which have been heavily extended)

These products are already demonstrable but a bit rough around the edges, I can take orders now if people are interested but there will be some more specific configurations advertised in a month or two, maybe with their own board designs or maybe targeted at commodity FPGA dev boards.

Hardware Components & Manufacturing Platform

This will involve small manufacturing runs using customised equipment, and will utilise the existing SecureLang® operating system which will be customised for testbench & hardware development workflows.

This won’t be aimed at mass production in my own workshop but will produce sample units and equipment/techniques for manufacturing, initially of simpler items such as individual transistors.

A particular focus of this product range will be helping to bootstrap manufacturing industries closer to mining areas/communities in Africa, Australia & elsewhere.

Reduced Software Focus (The Story)

I managed to finish most of my planned software and will be making good use of it with my hardware range.

I got disrespected greatly by a lot of people locally while I was just trying to invite people to demos and finish my code. Obviously people seem to think “programmer” means someone they can mock and threaten and rob and spread rumours about without consequences.

So from now on I’m going to be dealing with furnaces that are pretty hot, probably some high voltage equipment, really expensive materials that you probably don’t want getting in your eyes. And if anyone tries to fucking jump me by surprise with some junkie shit again while I’m trying to work and that person gets burnt that is their own problem.

It’s still early days but it looks like I can now confirm that – in the final hours, just as I was preparing to give up – my experiments in larger processors have been a success.

The 305/306 models are now working on at least one FPGA device, but the extensions and tuning are nowhere near complete.

Features (Working)

• Five-stage, single-issue pipeline
• RV64I instruction set

Features (Broken)

• An optional six-stage pipelined version exists, this actually does work in simple tests but doesn’t pass any reasonable timing constraints
• Hardware threading is currently completely broken on FPGA, builds with this feature are still fine in simulation but collapse when attempted in FPGA (this is probably just a small bug, missing some connections that the simulator ignores but hardware can’t)

Features (Untested)

• Some other classical optimisations exist but haven’t been fully tested on FPGA yet
• This includes register windows and delay slot execution (which can optimise simpler builds but is less useful in maxed out builds)

Other Plans

Once fixed up this should be great for extreme scale as you can just configure options to make an end device with as many hardware threads as you like. But, I need something faster too…

This will probably involve pairing a superscalar core with the scalable threaded core, this plan gives you multidimensional scalability as you can configure chips that run individual programs faster and/or also allow many efficient parallel threads.

More To Come…

There will probably be an official dev board combining my CPU, peripherals and operating system boot environment.

This Is A Bit Less Easy.

Smaller CPU designs are fairly easy to work with and will work on convenient FPGA boards.

Larger designs have proven a pain to get working on FPGAs. There are a lot of issues with larger FPGAs to the extent that I’d recommend starting CPU development on an underpowered one.

Issues with running designs on larger FPGAs include:

• Harder to get the tools working, will need to create accounts on very broken vendor websites to access downloads
• Documentation is fucked, I don’t know who they expect to be buying these things but printing a pinout with the boards would be fucking nice
• Examples that don’t work, tools that give warnings when you do things the example way, a weird sensation like the vendor didn’t actually want to sell you this product…

I won’t point out any specific vendors but basically they are all a bit shit (although their support teams can be helpful!), unless you buy the cheap models that are easy to program from a Linux terminal. With those you’re just a bit limited in the size of the design, they will only fit a simple CPU.

It Works In Simulation

It’s been easier to get features working in simulation though, so in a Verilog simulator my new design has the following features:

• Modern 64-bit RISC architecture
• 5-stage or (experimental) 6-stage pipeline
• Extremely efficient hardware threads implementation, designed for configurations with 4 threads per core
• Alternative optimisations for efficient/fast single-threaded implementations
• Very suitable for real-time device control or for further extension as server CPUs
• Based on a simpler MIT-licensed design, allowing for relatively easy commercial or open source licensing

Long Way To Go…

The current design looks and feels really solid, in simulation… There is no guarantee that it will ever work in hardware, maybe I will have to go back to the drawing board eventually but until then I’m working around the clock to make this design work.

There’s a chance that it will just work effortlessly in FPGA & in silicon once I figure out one more bug or get one more FPGA board working, but realistically it’ll take quite a lot more optimisation to get it fine tuned and also to add all the extensions developers would want.

Full Announcement Forthcoming

So I don’t know if this all is going to work right yet, I will reserve more detailed announcements until later.

If my new design does work this will probably become the basis for testing & deploying my OS code, otherwise the backup plan is I’ll probably scale back a little on my hardware designs and offer software/configuration support for existing designs instead (this will probably mean some less aggressive open source CPU forks). But for now of course I’ll continue working on bringing up this design on FPGA, which should work if I spend enough time isolating & testing each behaviour (my current testbench is just a bit of a mess).

So something will be coming either way, but for now I’m slowly progressing on the larger model which should perform quite well on large FPGAs if I can iron out the remaining bugs. This won’t be completely full-featured at first but should provide a good basis for extension.

Work on a larger CPU family utilising both new and legacy designs is underway. Proper announcements will follow.

The 210 Works On More FPGAs

The latest configuration has been tested on GateMate FPGAs and results in working builds (as determined by running a simple “flashing LEDs” program). This means that Gowin and GateMate are now supported targets, although it’ll take me a little while to clean up & extend the builds.

Higher-End Models Underway

I should have some faster base models uploaded soon based on third-party open source projects. So these initial models will represent much less engineering effort at my end but will hopefully form the basis of a stable processor lineup: hardened & supported versions of existing designs.

This currently involves experimenting with two different open-source designs, and provided that the basics eventually work I should be able to start uploading my changes soon.

Note that model numbers will not indicate newness but should roughly correspond to size of the design, and that the level of support I can offer won’t be exactly the same for each model (although at least some of my compilers will be portable to each).

Having To Think About Version Control…

I may just go back to using git as this seems easier for browsing projects & READMEs online, or I may release more over SVN as this is very convenient from my end.