Category: Uncategorized

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.

Features Of The 210

• Builds on my gen1cpu and the “200 Series” (gen2cpu) branch with improved cross-compatibility between configurations
• Native code built for either the 32-bit or 64-bit configuration can launch correctly on the opposite configuration
• This does not include full maths compatibility and compatibility between all extra features, only basic ISA & function call ABI cross-compatibility
• Maths still happens in 32-bit mode on 32-bit cores and 64-mode on 64-bit cores, but whether the extended bits are available can be easily detected in code
• These features are not properly tested in this version, and should be considered experimental for now

Possible Features (~220)

• Improved testing & FPGA support
• Will hopefully be tested & working on more different FPGA devices
• More/easier/faster memory access on common FPGA models, hopefully
• Possibly more I/O
• Huge overhaul of RISC Emulation
• This could include limited support for instruction sets of planned secondary processor lines

Model Numbers <100

These will be extra lightweight models designed to fit on practically any FPGA (a few thousand LUTs?) but may not offer modern CPU functionality (e.g. may be 16-bit designs).

Models ≥100 and <1000

These will be the primary models designed for beginner FPGA users (i.e. the range surrounding the current 200/210 model).

These will be 32-bit and 64-bit models targeted at the best FPGAs for beginners, and will need at least around 10,000 LUTs depending on model or configuration.

Models ≥1000

These will be the high-performance and/or legacy-compatible models, which will probably mostly be based on existing open source projects.

Following the first release of my second-generation processor architecture I’ve got a new update improving software cross-compatibility between 32-bit and 64-bit configurations.

This works by providing multiple instructions for reading/writing 32-bit chunks of data which can be ignored or interpreted differently when run on different processor configurations, allowing programs optimised for either target to launch smoothly and detect the environment when run on either a 32-bit or 64-bit core.

Although other features necessary for a viable CPU are still in progress, I hope to continue improving the core architecture and amplify key features like this which each update!

This update is in the final stages now and only represents a minor mechanical change with minimal testing but hopefully will be a major improvement to cross-compatibility between future models.

Brief Announcement

I’ve released a second-generation version of my processor core, this has some advanced CPU-like features but is suited for use with FPGA technology as a microcontroller.

After rigorous improvements still following from my original design, this version is now beginning to work in a more robust way and is now tested using compiled program code (the design is now stable enough to run loops & function calls).

Introductory Branding

The processor architecture will for now be referred to as the SecureLang® 200 or The SecureLang® 200 Series Microcontroller Architecture, in reference to each current version being a revision of the second generation processor design.

The current revisions may be called 204, 205, 206 and so on until a new major iteration, while some early documentation may refer to the architecture as 232 or 264 based on bit width.

The repository names are gen1cpu for the original (first-generation) version which can be found in a probably-broken form on GitHub and gen2cpu for the current 200 Series which is released over subversion. Open-source forks can use the genNcpu naming to refer to their or my freely available versions if they prefer to avoid any commercial branding.

Software Still In Progress

Only my Pascal-like subsystem fully supports the new CPU architecture at present, announcements about the operating system in general will treat it as a separate product for now.

Base Version Will Remain Free

The initial version of my processor design was made available freely and this will continue to apply to basic versions of the design.

Hardware Out Now (Only Catch Is…)

The latest versions of the design have already been released, current public releases are made over Subversion to see if this convenient:

https://svn.riouxsvn.com/gen2cpu/

The only catch is that this (second) version is still a very early test design which is only suited for use using FPGA devices or simulators. As such this version still has somewhat limited performance, but otherwise should be near to being a stable product.

For now this means you will need a SiPEED Tang Nano 20K device or comparable/better FPGA device and/or a laptop to test the design.

Hardware Specs

• Developed in Verilog for easy use on FPGAs
• Low footprint, requires <10,000 LUTs
• Supported by efficient, in-house compiler technology
• Available in both 32-bit and 64-bit configurations
• Optional management & emulation features
• Custom instruction set allowing up to 256 registers
• Limited but reasonable runtime performance (no advanced pipelining or caching features)

I’ve been working these CPUs a little hard, some big little things are coming to replace them.

The basic version of my font package is kind of finished, I have to restrain myself from tweaking the fonts too much but for now it’s a huge improvement over just having the legacy bitmap font.

In other news I’ve decided it’s probably easier to build my own hardware than to write drivers for everybody else’s so I’ll be adding some more FPGAs to my workflow but that may be pretty gradual before I get new tech working.

Work is underway on theming and font support, in a few days I should have some more styles to show off!

Semantic styling should be highly reliable but developers should be aware of some potential pitfalls.

Menus Can Be A Grey Area

Although semantic styling will generally work in all cases including menus, backends for third-party platforms may be more limited and the system may be unable to fit all the styling information into the standard menus on a given platform.

This shouldn’t be an everyday problem but may impact some early software porting efforts and could require some design attention: You may want to leave menu items in the default settings instead just for consistency or reliability.

The Screen/Backend Could Be Limited

If you’re developing a UI for a smart watch or for an industrial screen with limited or no colour support then you may just need to use a simpler GUI system.

Don’t Rely Too Much On Fonts

The current fonts in my system are extremely limited and the selection of fonts probably won’t be stable for a while, so don’t expect fonts to be reliable across different backends or across different system versions!

A GUI item either does or does not have a semantic style applied. This means there is no inbetween state where an item might have some semantic style information applied, it’s either turned on or turned off per-item.

When Semantic Styling Is Off

Then the GUI uses no semantic styling internally, so it just draws things like buttons using whatever settings are applied by the system.

This usually means the rendering and colour choices are quite different, e.g. the default may be to use a built in font renderer from the backend instead of actually selecting a font internally.

When Semantic Styling Is Turned On

If it’s blue it’s blue. If it’s bold it’s drawn thickly. If it’s Sans Serif or Times New Roman then the system should ideally try it’s best to find the correct matching font or inform the app of a problem otherwise.

The styling information is considered mission critical and is applied as much as possible, even if the system thinks blurple is a stupid colour, and it only affects layout when it changes the size of an item (e.g. larger/smaller font).

It Can Draw Things Plainly Too!

The semantic style information consists of a pixel colour (optional), a font (optional) and a set of flags. This means that, while semantic styling is decisively either turned on or turned off, when turned on it can also be used to indicate especially plain items. Themed backends in the future can use this mode to select more simple or less distracting rendering than the default.

Imperfect But Reliable

This behaviour shouldn’t be expected to be perfect but should be reliable. For example if you set a component to dark purple it may look more blueish or more reddish or darker or lighter depending on factors like theme, graphics backend, screen settings and button mode – however the button should be recognisably marked as being some usable approximation of your dark purple setting.

If a system theme or GUI backend can’t deal properly with the styling information then the user should still be informed of it, e.g. “dear blind person, this button in the thermostat is marked Red”. In more typical cases, this means that themes should fall back to the built-in rendering if they can’t process the semantic style (it’s considered more important than aesthetic theming).