Happy 100k!

Sure, it's not a million, but then again I'm not Arianna Huffington. Given how extremely niche these topics are and that blogging has been declared dead for about a decade now (about as long as I have been blogging, come to think of it), I think that a hundred thousand visitors is actually really really good. It's sure is a lot more than I would ever had imagined when I started doing this ten years ago.

The proof! Also notice the massive amount of followers this blog has gathered over the years

 

I don't remember anymore why I started blogging but I guess I felt that the world deserved to hear my opinions on random things. Also, there wasn't really anyone else writing about the things we were doing with OpenRISC and open source silicon in general at that time. Nowadays, any industry conference and news outlet worth mentioning will have FOSSi content but back then, most people in the industry just didn't get it. (To be fair, most industry people still don't get it given the number of "open source" panels I have seen at conferences consisting of people with zero insights who just sit there making up stuff because their companies have paid to have them there. Thank god for events like ORConf and Latch-Up!).

Enough about why. I thought it could be fun to look at how instead. There are a number of events that have lead to the magic six figure number. So, let's go back to the beginning. What was supposed to be the first article actually became the second article because when I wrote it I went off on a tangent and ended up with a whole article on scope creep instead. And I think that pretty much sums up my writing and how I (fail to) get things done in general by starting something and then ending up getting stuck in some detail and end up doing something completely different instead. Not that it really mattered though. The readership consisted mostly of friends who I forced to read the blog and questioned them afterwards to make sure they had read the whole thing. But I kept writing every now and then about different things around the OpenRISC archicecture. And then one day the people in my regular IRC chat channel notified me that my latest blog post was on the frontpage of Slashdot! For all you youngsters out there, Slashdot used to be the place where all nerds got their news and if you were featured on the Slashdot frontpage during its heydays you'd better have a server that could handle a massive influx of traffic. There were stories about servers burning up after being "slashdotted" because they were humble machines that never thought they would see so many visitors in their life. Luckily, 2014 was a bit after the heydays of Slashdot and Google hosted the blog so I don't think anyone got particularly worried about overloaded servers. But it did make some difference in numbers for the statistics for this humble blog.

The Slashdot effect in action

 

A couple of hours later, the Slashdot crowd moved their attention elsewhere and never came back, as is painfully clear from the statistics. I kept writing now and then however, mostly about FuseSoC, FuseSoC and FuseSoC which apparently didn't lead to any new front page news. A couple of years later though, I wrote about my complicated love-hate relationship with IP-XACT and that seemed to have struck a chord with some people. This one was more of a sleeper hit that didn't cause any immediate sensations but eventually became my most read, and definitely most cited, article I had written.

IP-Xact - an evergreen of confusing and questionable EDA standards

Getting noticed in premier geek media and cited in academic circles have both been happy surprises. There's no getting around that does feel a little more fun writing when you get these kind of validations. So I kept writing to a tiny uptick in readership after the IP-XACT article, again mostly about FuseSoC, FuseSoC and FuseSoC, but after starting way too many FOSSi projects over the years, like SERV, SweRVolf and Edalize, I also started doing yearly round-ups partly to remind myself what I did over the past year. And then one evening, after spending a day in a workshop with a clueless EDA vendor trying to shove their awful tooling down our throats, I wrote about one of the FOSSi projects that I believe will have a large impact the coming years, namely cocotb and how it will save us from SystemVerilog for verification. And that, my friends, turned out to be of more interest than anything I had previously written about.

Cocotb and Python coming to steal the show, as always

Suddenly, the hordes of geeks coming via Slashdot was just a blip on the radar compared to the angry, happy, confused and relieved verification engineers who showed up en masse to state their opinions, tell their stories, show their support or ask what this was all about.

Not everyone agreed, but it was clear that it was a hot topic. And that's the third thing I'm really happy about, to have ignited discussions around the status quo of chip design and get people to bring their ideas and opinions to the table.

I really hope to continue writing about stuff when I'm in the mood and can find the time. And hopefully some people find it interesting, at least occasionally. Given the sporadic output of the past, we will never know the next time that happens, so I'll just say until then!

OSDDI: Director's commentaries

Andrew Back of AB Open and FOSSi Foundation has been working on this great series of interviews called Open Source Digital Design Insights, in which he has been interviewing some of the great minds of the Free and Open Source Silicon movement (+ me). In the fourth episode the turn has come to me. As I watch the video myself, I realize how quickly time moves in the open source silicon world and how many things that have happened since then. I would therefore like to take the opportunity to add some more context as an addendum to the interview.

The interview was made at ORConf 2015, the same day as we publicly announced the Free and Open Source Silicon Foundation. We had been working on this for a year and it was a great feeling to present our ambitions to the world. The first thing that strikes during this interview is that we hadn't yet embraced the Open Source Silicon epithet ourselves and were still referring to our work as Open Source Hardware.

Another major theme that can use some more explanation is to role of the OpenRISC project nowadays. I would believe that most people coming in contact with open source silicon at this time will do so through the RISC-V project. When I started out, the RISC-V project was not yet born and OpenRISC was just about to become a teenager. OpenRISC wasn't the only free ISA around at the time. Most notably there were also free implementations of SPARC (both the LEON and the Sun T1/T2) and Lattice Mico 32 (lm32). OpenRISC was likely the most widely used architecture however and is still used in some critical infrastructure, which I'm unfortunately not allowed to speak freely of. Despite being widely used, the OpenRISC ISA hasn't been without faults, and already in 2011, we started work on a successor to the OpenRISC 1000 ISA, called OpenRISC 2000. Some of the things we wanted to fix was removal of the branch delay slots, better support for wider instruction lengths, instruction compression, more modular instruction set, revised memory model and other things. Unfortunately, we never got around to implement any of that, as we were a small group and there was barely enough manpower to do all the necessary work on or1k. Turns out, we never needed to, because a year or two after that, RISC-V came along and did all those things that we had planned for or2k - and more. In that regard, we see RISC-V as the spiritual successor to OpenRISC and we are happy to pass the dutch to RISC-V for future free thinking ISA development.

So what's the deal with OpenRISC in 2017? Well, it's not seeing as many design starts as it used to do since most new designs are based on RISC-V. My guess is that the ones who make new designs based on OpenRISC do it because they either already have a working OpenRISC environment and have no need to replace that, or because they know that it's a stable code base that has been ASIC-proven numerous times for more than a decade. On the software side we are still pushing to upstream some of the last bits of the toolchains, notably GDB and GCC. There are also some updates and clarifications to the specification, mostly related to the ABI.

I believe that the greatest legacy of OpenRISC will not be the ISA, but the idea and realization of a free and open source silicon ecosystem. A CPU isn't very useful by itself and much of what came out of the OpenRISC project was IP cores, such as peripheral controllers and a lot of support software. For example, the i2c and ethernet drivers for the controllers that came out from the OpenRISC project has been in the Linux kernel since 2006, which is seven years before the OpenRISC CPU support was added to the kernel. Some of the debug infrastructure that originated from OpenRISC is widely used in RISC-V-based designs. The FOSSi Foundation was born from a group of OpenRISC developers who saw the need for a vendor-independent group to foster the open source silicon ecosystem, regardless of which ISA is currently in vogue. ORConf was originally the OpenRISC conference. We have considered renaming it, but we like the name so we just have to find a good backronym (the best proposal is still Olof's Rock'n'roll Conference). Even FuseSoC was born as a tool to make it easier to build OpenRISC-based SoCs, and for the first year or two it was still called ORPSoCv3 (OpenRISC Reference Platform System on Chip version 3)

Enough said about OpenRISC. I think the most amazing aspect of the interview is that I did not mention FuseSoC even once. Nope. Not a single mention of FuseSoC in over 8 minutes! And if you think I look a bit like a zombie sloth on heroin in the interview, that's because I usually spend the months leading up to ORConf as Sonic the Hedgehog on amphetamine, so once everyone is seated and the conference starts, that's when I start to relax. It's a lot of work to organize a conference, but I absolutely love doing it and I hope that you will come to visit and enjoy as well.  And if you haven't seen the other entries in the OSDDI series, please watch them now. They really are insights in the world of open source silicon from some of the most knowledgeable people in the field (+me).

FuseSoC!

OpenRISC health report April 2014

About once a year, I'm at some conference to present the OpenRISC project for a new audience. One part of the presentation is often a quick rundown of all the things that has happened since the year before. Problem is that there's just too much stuff going on as the project continues to grow. To remedy this, I'm planning to write a small summary every month, or every quarter (time will tell), both to remind myself of what we are doing, and to make it more visible to the casual observer that there is pretty cool stuff going on with this nifty little CPU and the things around it. As this is the first installment, I would really have to present everything that has happened over the last 15 years to give a complete picture. I will not do that. You will have to settle with a back log from last year's OpenRISC conference.

While writing this article, I had to constantly ask for help explaining some of the concepts. This once again showed me how large this project has become and how much in-depth expertise that is shared by the participants. It also shows how fast things are moving, since most of the above items are things that has happened only during the last six months! I probably need to write a bit more often to avoid having to write a novel each time, but enough introduction. I will now leave the stage to OpenRISC and it's friends...

Debian for OpenRISC 

Perhaps the news item that has had the most coverage is the work done mainly by Christian Svensson to create a Debian port for OpenRISC. While OpenRISC, or rather the or1k architecture to be more precise, has been a supported target in the official Linux kernel since version 3.1, users have had very little support for creating a complete OpenRISC-based system. With the Debian port, things should be much simpler, and once the basic system is installed, your favorite package is just an apt-get install away. Naturally all packages aren't supported yet, and the package creation process has uncovered several bugs and missing features in the OpenRISC toolchain. The upside of this is that most of these bugs were fixed extremely fast, mostly by Stefan Kristiansson and Christian Svensson. As of now roughly 5000 packages have been built and packaged so far, thanks to Manuel A. Fernandez Montecelo. Many of the packages have been tested both in qemu and on a Digilent Atlys board with mor1kx. Apart from a multitude of library dependencies, the package list includes X.org, qt, scummvm, irssi and Fluxbox which means that you can now play games and chat somewhat comfortably on an OpenRISC system.

More information can be found here

Atomic operations

When running multiple cores, or multiple threads on the same CPU, each thread or core needs to know if someone else is currently trying to access an exclusive resource, such as an UART or a part of a shared memory. Normally this is done in software with mutex operation, such as semaphores or spinlocks, and the requirement for implementing a mutex is that an mutex operation is never allowed to be interrupted. Previously on OpenRISC this was done by making a syscall that disabled all interrupts as it's first instructions. That way it could make sure it wasn't interrupted by something else while it was busy doing it's work. Unfortunately this method is quite slow, and just doing ls generates  about 1700 system calls of which roughly 90% are mutex operations. Also, the syscall method won't work at all for multiple cores.

To improve the situation, Stefan Kristiansson has added two completely new instructions to the OpenRISC instruction called l.lwa (Load Word Atomic) and l.swa (Store Word Atomic). These two instructions form a load-link/store-conditional atomic operation, which can be read about in further detail on Wikipedia. Apart from the updates to the architecture specification, Stefan has implemented the operations in cgen CPU description in binutils so that the toolchain knows about them and can use them, the instruction set simulator or1ksim and in the RTL implementation mor1kx together with test cases.

An interesting side note is that while no OpenRISC implementation has ever had atomic operations before, Stefan found mentions of a pair of operations in a very early version of the architecture specification, and decided to reuse these names.

Multicore

OpenRISC has traditionally been used as a single core CPU in a SoC, but there is an increasing demand for spreading workloads over several cores in a system. Of course, it has always been possible to instantiate as many OpenRISC cores as you can fit in an FPGA or ASIC. The problems arise when they need to cooperate to share resources like main memory or peripherals (exclusive accesses), spread a workload evenly between them (load balancing) and making sure that their local caches are kept in sync with each others (cache coherency).

For several years, Stefan Wallentowitz has been working on the necessary hardware and software additions required for multicore OpenRISC as part of his research project OpTiMSoC. A few weeks ago he made an announcement that there now was a multicore OpenRISC demo SoC based on mor1kx running under FuseSoC. The required changes have been added to mor1kx, and apart from a special version of the newlib toolchain it uses unmodified versions of the software and hardware IP cores.

FuseSoC

During the last two or three years I have been working on a successor to the OpenRISC Reference Platform System on Chip (ORPSoC) that is used to run RTL simulations and provide a base for porting an OpenRISC SoC to a new FPGA board. The project was called ORPSoCv3 (to replace the old ORPSoCv2) and I did three releases before swiftly renaming it to FuseSoC. Why? you ask. Well, it turned out that there wasn't a single line of OpenRISC-specific code in FuseSoC, and I want it to be used as a general-purpose tool for building and simulating cores and SoCs for FPGA. This has become reality as it is now used for a SoC based on the eco32 CPU in addition to being the OpenRISC standard tool and other Open Source projects have shown interest as well.

Apart from the renaming and the never ending bug fixing, FuseSoC has gained many new features over the last six months. Some of the highlights include support for using SystemC in Verilator test benches, VHDL and using ISE to create images for Xilinx FPGAs. More detail can be found in the FuseSoC repository on github. The number of contributors continue to increase for every release which is a good indication that it is used by many people... or at least that many people find bugs.

ORPSoC Cores

The other part of the FuseSoC infrastructure is the collection of cores and systems that can be utilized by FuseSoC. The main repository is called orpsoc-cores and contains ready-made OpenRISC SoCs for different FPGA boards as well as the cores that are used on the boards.

Since October last year there has been added support for the very popular Digilent Atlys board, with ports for the LX9 Microboard, DE2 70, SoCKIT, NEEK and ordb2a in the works.

Many new cores have been added as well, and there is currently 39 supported cores in total. For more details see the ORPSoC Cores repository on github.

Binutils

The de-facto standard open source toolchain for creating programs consist of two parts. The compiler (GCC, with LLVM getting more common as well) and binutils. Binutils can be summarized as everything but the compiler. This means the linker, assembler, archiver and tools for modifying ELF files. OpenRISC support in binutils was added 14 years ago, but since then, no improvements have been sent upstream.

There has been a huge amount of work over the last years to improve the OpenRISC binutils support, and earlier this year it was decided that these changes should be sent upstream. Having them in the official binutils distribution means that anyone who wants to make binutils for OpenRISC can now use the official binutils package.

In the OpenRISC case, sending the changes upstream wasn't completely trivial even though the code itself was in very good shape, as FSF (Free Software Foundation) who owns binutils need to have the written agreement of all contributors that they are OK with giving away to copyright of the code to FSF. That means that the first thing that had to be done was to go through all changes and hunt down all the people who have contributed.

I volunteered to take on this mind-numbing job, which wasn't made any easier as we switched VCS from SVN on OpenCores to GIT on github a few years ago, and renamed the architecture from or32 to or1k. Luckily, most people had been very good with updating changelogs, which made things a lot easier. In the meantime, Christian Svensson had split up the OpenRISC-specific changes to a set of patches that was sent in for review. When that was done, all contributors had to get a copyright assignment document mailed from FSF to sign and send back. As the patches were already reviewed, the rest of the process went quickly by when all the mails had been sent back.

Stefan Kristiansson and Christian Svensson are now the proud caretakers of the OpenRISC port which should be included in the next binutils release.

musl

While there are many things that most people agree on, there seem to be no such consensus when it comes to standard C libraries. Everyone seems to have their own specific use case that requires a brand new C library. OpenRISC already has support for glibc, uClibc and newlib, but the new kid on the block when it comes to embedded software is musl. musl is designed to be small and portable which suits the OpenRISC use case just fine. Stefan Kristiansson has prepared a musl port which is mostly done apart from some details about syscall handling that needs to be resolved first. Now we only need to port bionic and we're ready to take on Android.

mor1kx

The up-and-coming mor1kx OpenRISC RTL implementation is rapidly gaining new features, perhaps as a testament to it's more modular design compared to the original or1200 implementation. In addition to the atomic operations mentioned above and multiple bug fixes it now supports caches with more than two ways,  and the ability to reading the GPRs through the debug port.

ORconf 2014

Last year's OpenRISC conference in Cambridge, England was a great success and attracted participants from both academia and the industry. As for this year, Stefan Wallentowitz has kindly offered to host the conference at Munich University. Initial planning has started and nothing is set in stone yet, but it will probably be carried out the weekend October 11-12. More information will become available at http://orconf.org over the coming months.

initial begin

Software is built up by layers and layers of abstractions, which has the pleasant effect of hiding all the underlying madness that computer software is built upon. If we still would be fearless enough to take the long and winding road down a user facing application, through the libraries, operating system and drivers, we would eventually end up at the register map. This is an impenetrable wall even for most of the hardcore close-to-the-metal low-level-driver gurus. This is the boundrary between the chips and the instructions that are meant to make the chips do something useful. This is however not the final frontier. Some fearless souls, calling themselves FPGA/ASIC designers, Digital Design Engineers or Hardware Developers have decided to take the spirit of Open Source and Free Software beyond the wall and into the realms of the silicon. In the Open Source world, hardware is generally considered Open Source friendly when there exists a documented register map and perhaps some use cases, so why do more? Well, for us on the hardware side, we want a little more than that. Hardware can be just as buggy as software, and working with closed-source IP cores are generally a pain. This ranges from the obvious problems that you can't debug your code properly to the insane license agreements and in many cases strange restrictions that the license holder can impose on the development environment. While these are all very practical reasons for doing all this, I think that the driving force for most of us is that it is pretty damn fun!

I, myself, come from a background of having worked professionally with FPGA and ASIC as a consultant for five years now, and been involved with software and hardware since my first stumbling peeks and pokes in QuickBasic in the mid-nineties. Over the years, I have enjoyed the great success of Open Source Software and contributed back to a bunch of different projects. In 2010, I got involved in the OpenRISC project, through my employer at that time. These last three years working on the OpenRISC project in my spare time, I have found myself in company of extremely talented people who are not afraid of learning new things or take on overwhelming challenges. Combined with a large ecosystem of IP cores, toolchains, operating systems, test suites, documentation, development tools and basically everything else you expect from a processor architecture, this has come to be a huge and very interesting project.

The main reason for starting this blog is to shed some light on all the things we are working in the digital domain of the Open Source ecosystem, and in particular the OpenRISC project. Searching around the internet, it turns out that the amount of written information is sparse. Apart from our ever-growing official OpenRISC page that holds our ever-growing wiki and links to most things related, Sven Andersson has written a series of articles about his experience with the OpenRISC as a newcomer to the scene. This has provided us with great feedback for how we can improve and streamline things, as well as getting many people interested in trying out this mythical CPU creature. Franck Jullien has also written some articles on his blog about his work with some cool debugging features for OpenRISC. Another resources that has served well over the years are a series of application notes from Embecosm on SystemC modelling, GDB protocol implementation and C libraries, written by long-time contributor Jeremy Bennett. Many of those articles has found use also outside of the OpenRISC world. There are probably many more articles that I have forgotten about, and it would be great if everyone who feel left out can come forward so that we can collect a definite list of all related articles. In addition to written articles, many of us like to show up at conferences to talk about what we do in the project, hang out and hack on things. Julius Baxter and I have held presentations (here and here) and a workshop at FSCONS and visited FOSDEM last year. 2012 was also the year that we held the first (hopefully annual) OpenRISC Conference, which was a great success. Sitting through the presentations, it was clear that the project is growing and that an impressive amount of work is being done by extremely talented hackers.

While all of these articles and presentations has given us a chance to show what we are doing, there are still a lot of really cool development that goes unnoticed for the unitiated. I hope to get some time to write about all the fun stuff that is going on, and most of all, write about all the fun stuff that I am doing.

Most of my own work isn't directly related to the OpenRISC CPU itself, but on the infrastructure that surrounds it. I'm maintaining an ethernet MAC, has started an extremely low-volume mailing list on the Wishbone bus (which is the bus that OpenRISC as well as a few other Open Source CPU:s use to connect to other IP cores), done some C library hacking, fixing bugs, reminding other people about forgotten patches and fixed bugs and been around to companies, conferences and schools to talk about using Open Source IP cores in their workflow. Since about two years my main focus has been on creating a platform for simulating individual cores as well as simulating and building systems based on the many fine IP cores that are available at OpenCores and other places. The project is called orpsocv3, or the OpenRISC Reference Platform System on Chip version 3, and is planned to replace our current platform orpsocv2. orpsocv3 is packed with functionality that will hopefully make development easier compared to the existing system, and will hopefully be prominently featured in coming articles. The code is still in an early development stage, but you can check it out here if you want to to see for yourself what all the cool kids are talking about. To avoid the infamous scope creep, I'm resisting the urge to write more about orpsocv3 now and instead conclude that proper introductions have been made and we can go on to the technical stuff for the next post.

end