Community Insights: Julius Baxter (OpenRISC)

Julius Baxter is a core team member on OpenRISC, a project that is developing a family of open source 32 and 64-bit RISC CPU architectures. In this interview Julius provides us with the background to OpenRISC and his involvement, and covers some of the benefits, practical considerations and future plans for the project.

Can you tell us a little bit about OpenCores. 

OpenCores began as a place to host open source hardware project about 12 years ago, and was started by the initial group of OpenRISC developers who were mostly, at the time, students in Slovenia. It still is the largest open source hardware project repository around.

And can you tell us about the OpenRISC project.

The OpenRISC project aims to develop microprocessor architectures and open source implementations. That is architecture specifications, the first of which is OpenRISC 1000, and open source implementations of CPU cores written in a hardware description language (HDL) like Verilog, along with software, verification suites and tool chain ports. At present the most widely used CPU implementation is the OR1200, which performs quite well for a 5 stage pipeline CPU and is capable of running Linux.

How did you get involved with OpenRISC?

I had done some work on a soft core microprocessor while I was doing undergraduate studies and in 2008 I started working for ORSoC who are the owners and operators of OpenCores since 2007 and also run a consultancy which, amongst other things, specialises in the OpenRISC technology.

Who are the typical users of OpenRISC?

It's handy for anyone who is looking at developing a System-on-Chip (SoC) on FPGA and who wishes to have a truly open source implementation for either the cost or technological advantages. This may be students looking to learn about RTL or CPU design right up to developers of industrial control units or avionics.

How much does the hardware required to experiment with OpenRISC cost?

The most basic kit we have a ready-to-go built for would be the Terasic DE0 Nano ($59 USD for students, $79 otherwise) which can run RTOSes but wouldn't have the resources to boot the kernel

The OpenRISC development board developed by the guys at ORSoC, in order to encourage people to play on the platform, is available through OpenCores for practically cost price at 139 EUR:

Other boards with larger amounts of peripheral ICs and capacity include the Digilent Atlys board.

Has the OpenRISC been used in any ASICs?

Yes, various things throughout the years, but nothing to my knowledge where it has been documented for developers to play with, unfortunately

Why do you feel that the work of OpenCores and projects such as OpenRISC is important?

I'd really like to see the open source digital design projects have as much success in terms of use and development as their open source software cousins up the stack. There's a couple of reasons why this hasn't happened yet, and why it may be a struggle to make happen, but on balance I can't see where there shouldn't be more uptake of open source digital design by ASIC companies and FPGA developers. So I think the work of OpenCores and the OpenRISC project can help make that a reality by showing that this stuff works and is worthwhile.

Could you ever see a community designed processor or SoC competing with a commercial design?

For FPGA use, certainly. In terms of ASIC, I'm less hopeful because they're expensive to develop and prototype and the cutting-edge fabrication plants are very unlikely to allow their process specifications and libraries to to be made publicly available. This matters because if you want to be a competitive implementation you must, for one, have competitive power use, and to achieve that you must know the details of the implementation technology.

The other issue is that the EDA software to used to turn RTL into a mask set is very specialised and expensive. To implement an open source set of tools such as that would probably be an even bigger task than coming up with a SoC design! There's certainly people working on this stuff, though, and it could happen, but the situation at the moment is that if you want your RTL turned into silicon, you need an amount of money that makes the activity prohibitive to almost all.

In what ways can people contribute to the OpenRISC project, e.g. do they need HDL skills?

There's a lot of components being developed in the project, most of which are, actually, not hardware related! Tool chains, simulators, software in kernels and applications. If you go and look at the project page on OpenCores for something you're interested in, feel free to email the maintainer or post to the mailing list asking how you can help out.

On the hardware front, though, we're really looking to develop our next incarnation of our SoC project, ORPSoC. This will aim to improve verification and usability of the system as a whole.

What would you say to those who are interested in experimenting with OpenRISC but that find the idea of HDLs daunting?

There's plenty of information out there to help ease you into the project, and you don't necessarily have to type a line of HDL to get your own SoC simulating or running on an FPGA board. The ORPSoC project provides bush-button builds which go from source to a programming file.

Where do you see OpenRISC going in the future?

There's lots cooking at the moment, if I may mentioned that first. We have seen a few new CPU implementations crawl out of the woodwork of late (my own included) which should provide a greater range of implementation possibilities. We've had a few guys bringing the tool chain up to date with GCC mainline, and even an LLVM port in the works. There's been work going on a QEMU port, too. We've had contributors working on a fully automated build system, making it very easy to build, install and test several components of the platform, very handy! Adding to our Linux kernel port we've had people getting U-boot upstream, and an eCos port which is progressing well.

As far as the future for the project is concerned, I can see it progressing upon its solid base of contributions we've had in the past few years and ultimately hopefully making it easier to use and develop. Architectural evolution is also on the cards with some of us looking to solve some of the architectural drawbacks of OpenRISC 1000 in a new generation architecture we've dubbed, unsurprisingly, OpenRISC 2000. Aspects such as code density and multi-processor support are certainly going to be addressed.

Thank you for your time, Julius!