Monday, 4 May 2015

LowRISC

lowRISC

Discover a project that's hoping to get us one step close to a completely open computer.

It doesn’t matter how open or free your software is, the only hardware available today is closed and proprietary. This closed hardware could be used to compromise the freedom of computer use in many ways. Closed hardware can be used to limit what the user runs, the way in which it runs, or what other hardware it runs with. You also can't see how closed hardware works which makes it harder to inspect or improve. Until we have open hardware to go with open software, well never have truly open computing. One project hoping to change this is LowRISC.


This project is attempting to design and produce an open system on a chip (SoC) that could be used as the heart of a Linux computer. An SoC is like the motherboard of a traditional computer - it contains the processing core, and much of the associated circuitry for input and output. The only part of the main system not included on SoCs is the memory.

Having a fully open SoC would put us one step closer to a fully open computer, where the user could inspect the source code for any element of it. Having an open SoC would mean no closed-source blobs to get it to run. It would mean the possibility of a completely libre computing environment.

In hardware terms, the source code is the design in a hardware description language (for example Verilog). This compiles to hardware designs in a similar way software source code compiles to machine code. An open chip has to have the code for the hardware description language open so anyone can see it edit it, and re-distribute it.

The SoC industry is known for its secrecy. Even getting information about how to use particular chips can mean signing wide-reaching non-disclosure agreements, so an open alternative here would make it far easier for smaller developers and hobbyists to work with these chips.

Freedom and features


As well as being open, there are a couple of key features that make LowRISC stand out. According to Alex Bradbury, co-founder of the LowRISC project: "I guess the notable features that we're looking at adding are tagged memory support and minion cores. Tagged memory gives you the ability to annotate memory locations to, say, limit access for security purposes, and minion cores are very small, simple RISC-V processor."

These two things make the LowRISC SoC different from other offerings - even commercial chips - but for very different reasons. Tagged memory is basically the ability to mark certain chunks of memory. In the LowRISC solution, this will mean that every 64-bit word will have an additional two bits of memory associated with it. These two bits can be used to add some context to the word so the processor knows what should be in it. This is most commonly used to enhance security. For example, if an attacker manages to write to memory - such as through a buffer overflow - the processor will be able to see what type of content the memory should have, which will make it harder for the attacker to turn this exploit into code execution.

The minion cores are additional processing cores that sit on the input/output pins. These can be programmed to handle some of the 10 activity. For example, if you need a pin to communicate using a particular protocol (such as I2C, which Nick Veitch investigated in LV012 and 013), the minion core can handle the low-level aspects of this communication without taxing the main CPU.

Most SoCs have hardware to handle I2C on a few pins, but the advantage of the minion cores is that you can use whichever pins you like for whichever protocol you like, rather than the current situation where protocols are tied to particular pins (as anyone who's used the Raspberry Pi GPIO pins will know).

In many ways, the situation with minion cores is a little like having Arduino microcontrollers sitting between the CPU and the 10 pins. For anyone building custom hardware, this could be very useful.

Although LowRISC is trying to make a fully open SoC, it won’t be able to completely avoid proprietary code from the first version. Alex Bradbury told us: “As for all this open source stuff, there are a whole bunch of lines that you can choose to draw. The lowest aim is for everything that you would implement in a hardware description language (like Verilog) to be fully open - so all the digital logic is fully open. [However,] it might be that in the initial case, we need to take on some closed source intellectual property for some 10 controllers, because often the physical interface is very tightly integrated and tightly tied to the controller. It might just be too much engineering work for the first chip.”

While we do feel that it’s a bit of a shame that the initial SoC won't be completely open, we understand the need to be pragmatic when bringing something as complicated as an SoC to market. Since the RAM will be in a separate chip, this closed source code will just be dealing with the interaction with that memory. This is something, Bradbury explained, that the team would like to open in future revisions.

LowRISC isn't the only project trying to create open source SoCs. OpenRISC has been around a lot longer and has several designs that can be implemented on Field Programmable Gate Arrays (FPGAs). These are chips that contain lots of logic circuits and a mechanism to connect these circuits in different ways. This means you can download different hardware designs onto the chip and run it. It's a cheap way of trying out different designs.

There are some important differences between LowRISC and OpenRISC. “I suppose the comparison between first the OpenRISC versus RISC-V, the difference would be that RISC-V is a clean slate, 64-bit ready rocket architecture with a very minimal instruction set whereas OpenRISC perhaps made the mistake of throwing in too many instructions into their basic architecture,” says Bradbury. "It's taken them a long time to get a 64-bit version and adding atomic support, that’s just about happening now. I think there are very friendly people in the OpenRISC community and most of them kind of see that if they did a clean 64-bit OpenRISC, it would probably look something like RISC-V. Indeed there is a fair share of lineage.”

Performance


The crunch question for any new computer is what speed will it run at: "The aim that we discussed for our first meeting is to run Linux well. This is what we’re looking at: dual- or quad-core running at 1 -1.5 gigahertz, the exact clock speed will depend on if the production process ends up at 40 nanometers or 20 nanometers.” The process size refers to the smallest imprints that can be made on the silicon. The smaller process would mean a faster chip.

Running Linux "well" is a - perhaps intentionally - vague target. For many users, the limiting factor of the first LowRISC SoC will be the lack of a GPU. This means it will struggle with most desktop uses. However, there are still plenty of applications where this isn't such a problem: "There are a number of people who are particularly interested in security-type applications [because of tagged memory]. Given that we ship without a GPU, an obvious use case would be a router. Right now it is a real problem that you buy your off the shelf hardware and it is running some firmware that you can not change that was written six months ago already has a local root vulnerability you cannot patch around."

Obviously routers are not the only hardware that doesn't need graphics but that does need good security, so we expect to see a lot of projects pop up once the hardware is available.

Community


If this sort of thing sounds interesting to you, then the LowRISC team are keen to find people to help out: “We’re very welcome to contributors, we want people to get involved," says Bradbury. “Right now, as with many open source projects, the documentation isn't quite where we want it to be. But in the future, if somebody here is interested in learning more about hardware design and about how you can apply some skills that you might already have in software to the hardware world, then we want to be the source of that. There are all sorts of levels you can get involved, from people who have some basic software knowledge and want to work on software reporting to people who want to work on documentation."

This isn't just an abstract hope for the future. Already open source contributors are making key additions to the project: “One of the pleasing things that we found was that when we first announced what we are doing with the project - which was sometime last year - it coincided with some press from the Berkeley team [who are creating the RISC-V core]. We were a little bit apprehensive about doing that because we did not have an FPGA thing ready.

We thought we should wait a bit longer, but what we found is that we have been able to move at a much faster rate than we would have done otherwise due to people contacting us and offering their help to bring in some ideas. Right now there are a number of people who have been very helpful in terms of making suggestions about design decisions."

Bradbury continues: "We started seeing more design discussions go on the normal mailing list about how things such as the link between the application cores and the minion cores should work.”

The biggest difference between an open hardware project and an open source software project is that it's effectively free to compile software, while it can be very expensive to make new hardware. Alex told us how LowRISC has overcome this hurdle: "We are very lucky to have some initial funding from a private backer, which is about enough to get us off the ground and have some people working on it through to the initial test. We have access to loans... and we’re also applying for more traditional research funding and for the research aspects of the chip.’

The start of something big


"When it comes to producing the final board, we may well end up doing a crowdfunding campaign if that seems a sensible way to go, but we decided it is not something we want to do until we are basically almost there and it's just the case of needing the money. Right now there are too many unknowns and people wouldn’t know exactly what they were buying, so I do not think it would be quite right to start at this stage."

With the money in place, the LowRISC team hope to have something for us soon. The initial test run of chips should run toward the end of 2015 or at the start of 2016. This won't be a full-scale production run, but will produce enough for there to be some available for people in the community to start developing software ahead of a main run later. You don't have to wait until then to start playing with LowRISC though. The team are putting together a version that you can load onto an FPGA board: "If you go to the RISC-V website you can download Rocket Core, which will run on a Zynq FPGA. We have an FPGA-ready version with tagged memory, and then some time this summer some of the minion cores as well."

You can stay up to date with the project, or get involved with the development, at www.lowrisc.org