onsdag 28 april 2021

A first look at Edalize for ASIC flows

Over the past years there has been a revolution in open source silicon. While there have been open source IP cores and open source chip design tooling available for at least 25 years, a lot of this has been disparate efforts. What we see now is that many of these projects are coming together as a tour de force creating a snowball effect of generating more projects and innovations being built from these earlier efforts. As I mentioned in my 2020 retrospective, we finally reached an important milestone last year where it’s now possible to create an ASIC using only open source code and tools. And within the limitations of the tools and technology this works just fine for one-off designs. Scaling this up has been a problem however. We see the same tasks being manually repeated and RTL files being copied over and over again instead of focusing on making more exciting end products.

A big part of this has been the lack of tooling to make it easier to use and reuse existing designs. If we had been developing a software project we would just had used pip, apt, npm, cargo or similar to bring in the bits and pieces in the form of packages that already exist and focus on our core functionality of the project.

And similarly if we are developing a complex FPGA product we would use FuseSoC, the award-winning package manager for IP cores, to quickly bring in pre-existing IP cores to the design we're working on and send the whole design to your simulator or FPGA toolchain of choice, allowing us to just care about the parts of the design that does not already exist.

Wouldn't it be nice if we could have that for ASIC implementations as well? The good news is that we are almost there.

Aided by funding from the NLNet NGI0 PET fund, Qamcom is now extending Edalize with a new backend for ASIC implementations, starting with the OpenLANE flow. The work is being done primarily by Klas Nordmark and me (Olof Kindgren)

Edalize+ASIC=Edalasic...or maybe not

 

The overarching goal of the project is to allow users to quickly onboard their existing FuseSoC-enabled designs to the OpenLANE flow by just adding a bit of OpenLANE-specific information to the core description file, run FuseSoC and get a GDSII file, making it just as easy as it already is to create an FPGA bitstream or a simulation model.


The FuseSoC+Edalize flow in all its glory


To further aid users starting out their ASIC journey, we have started developing a reference project called subservient, which is a small SoC based on the award-winning SERV, the world's smallest RISC-V CPU. The subservient SoC  can be found here.

 
subservient: The pocket-sized RISC-V SoC for your every need




We are also working on adding FuseSoC support for the OpenLANE examples and would also like to see support in... well, pretty much everything. And here's where you come in my dear readers. As has been the case from day one of FuseSoC development, it’s important to test the flow on as many different designs made by as many different people as possible to make sure to not build in any assumptions we might make from our own designs. So please take your designs through the FuseSoC flow and let us know how it went. If not for our sake, but to see yourself how many gates and how fast your design would be in an ASIC, and make a pretty GDSII file that you can show friends and family. That's one part that I have looking forward to see for my own designs



subservient SoC in SkyWater's 130nm process: The Mona Lisa of GDSII files

Being an open source project with a strong focus on collaboration, perhaps the most important question would be, How can I get involved?

 
First of all, whether you have some opinions, want to hear how things are going, have questions, need help or just want to be a fly on the wall you can find us in the Edalize chat room

Trying out the reference flows is valuable to make us understand where documentation or implementation is currently lacking, and if you come across any problems please let us know by filing a bug report, suggest improvements to the code or documentation or even fixing the issue you found yourself. Being a work in progress means you might hit some bumps in the road, but it also means you have an opportunity to help out deciding the best solution.

And as mentioned before, adding FuseSoC support for your own cores is valuable since it makes it easier for you to run it through different flows and for other people who want to use them as is or as a part of a bigger design. Don’t worry. Adding a FuseSoC core description file is in most cases very straight-forward and doesn't put any additional requirements on your code. We’ll help you figure out the problems if it doesn’t work. Also keep in mind that the larger the ecosystem of cores become, the higher chance you will find the cores you need next time you start a project.

“Focus on your core business, not your cores” C. McCoreface 2019
 

 


 


torsdag 25 februari 2021

FuseSoC 1.12

It's February 25th 2021 today and you all know what that means! It's time for another FuseSoC release! So what happened since last time? Well, let's find out.


 

 First of all, as I mentioned in the 2020 retrospective, most of the work during this development cycle has been done by Philipp Wagner. Thanks Philipp! He wasn't the alone though. This release had in total 11 people contributing code and looking at the history this is the most people contributing on a single release ever. As always, I'm really happy to see the project grow, so thanks everyone for helping out.

This release should perhaps also be seen as a bit of calm before the storm. Practically no user-facing feature additions were made to the code, but a lot of things were done to make sure FuseSoC is in good shape for upcoming changes and to provide users with a more polished FuseSoC experience.

Testing

There was much focus on improving the testing on FuseSoC this cycle. Tests are vital to make sure that things don't break when the code is changed and that existing code really does what it is supposed to do. tox is now the preferred method for launching tests and has the benefit of being run in an isolated environment and therefore not requiring FuseSoC to be installed, or accidentally run the tests on another system-installed version of FuseSoC. The latter has actually caused a lot of headaches when you could sometimes make changes that were expected to make the tests fail but they still passed because they were not run against the version you had changed. But that's all in the past now thanks to tox. The tests also cover more functionality, mostly things that were discovered to be broken because there had previously been no test to detect when they broke. Related to testing FuseSoC, switched to using GitHub for CI instead of Travis and Appveyor

Cleanup

This cycle also contained a lot of my favorite pastime - removing things. Code is a cost, not an asset, and removing things makes it easier to focus on improvements. Cleaning up can be done at almost all time, but recent changes such as dropping Python 2 support, and perhaps more importantly a fresh pair of eyes, resulted in a lot of cleaning up this time. A lot of this was done internally, but also on the user-facing side there were some changes. Up until now there has been potential for mischief by specifying paths in the core files pointing to files outside of the core root. This was never meant to work and users trying this now get a proper scolding.

Two commands were marked as deprecated, pgm and init. For the former, the equivalent functionality can be accomplished by using the run command instead with the --run switch (Yeah, I know. It's not the most obvious syntax). The latter, which is intended to get the standard FuseSoC core library, can be done with fusesoc library add fusesoc_cores https://github.com/fusesoc/fusesoc-cores instead.

Also deprecated were the (probably since long broken) logicore and coregen providers. Those were always intended as a stop-gap measure and their job is better handled by a generator, using the EDA tools tcl API to generate IP cores or add .xci files to your core file. The best alternative depends a bit on the situation.

The last thing to be deprecated is the CAPI1 core description format. FuseSoC will keep supporting CAPI1 cores until FuseSoC version 2.0.0 comes along at some point in the future but it is highly recommended to update already now. And thankfully a core conversion tool is now available. The FuseSoC migration guide goes into more detail on how to use that. And in parallel to this deprecation, all CAPI1 cores from the FuseSoC standard library have been converted to CAPI2.

And finally, the already deprecated build and sim commands were removed in this release. Those commands were written for a CAPI1 world which no longer exists other than in our memories. The run command has since long taken over.

To get your code base ready for FuseSoC 2.0 (which shouldn’t be too far away) we recommend that all users address all deprecation warnings as soon as possible. Deprecated features won’t go away in FuseSoC 1.x, but will be removed in FuseSoC 2.0.

 Documentation

We have good reasons to celebrate the 1.12 release of FuseSoC. One of the most prevalent problems has been fixed, that of unreadable or non-existent documentation. Philipp has done an amazing job in rewriting the documentation pretty much from scratch, dividing it into different sections targeted for users and developers as well as trimming down the readme file from its previous stream of consciousness into an elevator pitch for engineers. Also building the documentation should now be easier for those who wish to do so.

So are there really no new features whatsoever? Not really. As mentioned initially, we have been holding things off to make sure there's a solid base to start from when we unleash a flurry of exciting features.

Ok, I snuck in a small feature, which turned out to be pretty much my only contribution this cycle. It is now possible to set parameters for generators directly in the targets. What does this mean? It's probably easiest to show with a small example. Imagine two targets, each using a generator to, say, select the number of really small CPUs to be instantiated in the design. This is configured by setting the count parameter in the generator to the value appropriate for each target.

targets:
  target1:
    generate: 
    - morecoregen1
  target2:
    generate: 
    - morecoregen2

generate:
  morecoregen1:
    generator: morecores
    parameters:
      count : 11
  morecoregen2:
    generator: morecores
    parameters:
      count : 73 

Maybe it's just me, but I think there's some obvious areas for improvement here, so from now on, you can do it like this instead.

targets:
  target1:
    generate: 
    - morecoregen: 
      count: 11
  target2:
    generate:
    - morecoregen:
      count : 73

generate:
  morecoregen:
    generator: morecores

Pretty nice, ain't it?

tisdag 23 februari 2021

FOSSi Fever 2020



2020 was a year with a lot of bad news and so it feels slightly strange to cheerfully write about a very specific topic in the light of this. But there will always be good and bad things happening in the world. So let's keep fighting the bad things and for now take look at what happened last year within the amazing world of open source silicon. I will start by mentioning the most significant, but by no means the only, milestones for the FOSSi movement as a whole and then take a more personal look at the work where I have been directly involved.

OpenMPW

The biggest story within free and open source silicon this year has undoubtly been the openMPW project involving Google, SkyWater Foundries and eFabless together with a number of other collaborators.

Ever since I got involved in open source silicon ten years ago, building a fully open source ASIC has been one of those big milestones. While we have had FOSSi IP cores taped out on chips for at least 20 years and parts of the flow being managed by open source tools, it has always seemed to be too much work and requiring filling in too many gaps to have a fully open source end-to-end flow to produce ASICs. But, over the years people all over the world have filled in the gaps and done the work bit by bit. Sometimes in the context of overarching programmes to advance open source silicon, sometimes in academic settings, sometimes coming from the industry and sometimes as completely unpaid hobby projects. And this year all these efforts came together, helped by funding, to produce four shuttle runs, each loaded with 40 different completely open source designs. The first of these runs are currently being fabricated, and it will be extremely interesting to see them coming back.

One of the final pieces in this puzzle was the PDK. And while SkyWater should be rightfully lauded for their decicion to open up their 130nm PDK, it begs to ask the question: Why on Earth did it take this long? What could possibly the fabs have to lose by doing this? What they gain is easy to answer, a completely new market of users who can create chips at their fab. According to people within the project, it's estimated that 75% of the people on the first shuttle define themselves as software engineers. It's very likely that none of these people would ever dream of making an ASIC without this possibility. So I kind of feel that making the EDA industry open up their formats is a bit like trying to get your kids to eat vegetables. It's a lot of groaning and complaining, but was it really all that bad in the end to get some nutritions. Or in the case of ASIC fabs, was it really all that horrible to release your PDK to get some more customers? Let's just hope this opens up the eyes of more fabs. My, and many others, dream is to eventually see the same thing happening to ASIC fabs as has been happening with cheap PCB services over the past ten years. And using that analogy, I'm quite sure it pays off to be early in the race. So, get started folks!

QuickLogic and SymbiFlow

The other big thing happening this year is that we finally have an FPGA-vendor shipping an open source toolchain for their devices. The company that will go down in the annals of history for being the first to do this is QuickLogic and their EOS S3 FPGA. This is by no means the first FPGA with an open toolchain, and the QuickLogic-flavored version of SymbiFlow developed by FOSSi veterans Antmicro is based on all this prior work. But it is the first time we see a toolchain being created from the FPGA manufacturer's specifications rather than being figured out from compiled FPGA binaries and it's the first toolchain that is supported and funded by the vendor rather than being at best tolerated by them. And again I must ask, why did it take so long for this to happen? If I was running a small FPGA startup with limited resources, I can't for my life understand why I would want to spend a lot of time and money to build and continouosly maintain a big unwieldy toolchain all by myself instead of adding the required device-specific bits to a known good open source toolchain and share the maintenance burden. If nothing else it would free up resources to build other value-add products on top of the tools. It's like if every vendor of computer systems would first build their own operating system and compiler before shipping their products. This is what we had in the 80s and abandonded it for very good reasons. Because it made absolutely no one happy. And you know what? I think the users of FPGAs should put more effort into pushing their vendors to support open source toolchains, because it will save everyone a heap of time and money.

Let me illustrate that last point with an example that actually happened when I was porting SERV to the QuickLogic devices. After synthesis I noticed that it used far more resources than expected. Looking at the synthesis logs I realized the memories in the design weren't mapped to on-chip SRAM. So I asked the toolchain developers about this. They pointed me to the file in the toolchain that contained the rules for mapping to SRAM. I quickly found a badly tuned parameter, changed it to a more sensible value and ten minutes later it was working fine. An hour later I had submitted a patch back to the toolchain that fixed the problem for everyone else who would encounter it.

let's break this down into numbers. Finding the cause of the bug took about 15 minutes. Fixing it, another five. At that point I could use it myself, but after spending another 15 minutes or so, it was also fixed for everyone else.

Now let's do the same exercise for a proprietary closed source toolchain. Finding the cause of the bug takes... well...it depends... Let me explain.

I started my professional career at a company which at that point was the world's largest FPGA buyer. Whenever we had problems, they flew in two FAEs to sit in our lap, they could provide us with custom internal builds of their tools and generally tried to make sure the problem quickly went away so that we would continue to buy FPGAs from them. However, most companies are not the world's largest FPGA buyer and does not get this treatment. Instead you will have to wade through layers of support people until you reach someone who is actually qualified enough to acknowledge the issue. I have been in this situation numerous times and would estimate this process usually takes around 2-3 months. Actually fixing the bug probably takes five minutes or so in this case too, but here comes the fun part. In most cases you will now have to wait, I don't know, a year or so until the fixed bug ends up in a released product that you can download. What happens in practice is that the user tends to find a workaround instead. In the example above, the likely solution would be to instantiate a RAM macro instead of relying on inference. This however doesn't come for free as it requires finding all the instances where this is a problem, add special handling for this case which results in a larger code base with more options to verify and maintain. This costs time and this costs money. So the moral of this story is that closed source tools are more expensive for everyone involved and users of FPGAs should get better at telling the FPGA vendors that they are done with this closed source nonsense.

The QuickFeather. First FPGA board to ship with a FOSSi toolchain




There are numerous other news and projects that are well worth mentioning, but the above two are milestones that we have been waiting for a long time, so they deserved special attention. And if you want to keep up with the latest happenings in open source silicon, I highly recommend subscribing to the El Correo Libre newsletter which does a fantastic job of providing an overview of what goes on in all corners of the world. So let's move on to some of my more personal victories that aren't necessarily mentioned in other people's year in review.

When I am working on and talking about open source silicon I am often wearing many hats because I'm associated with several different organizations. Luckily they are all pretty much aligned on this topic which makes things far easier. But these organizations also have different motives and goals so I would like to mention a few words about them here. 

Qamcom

My dayjob is working for Qamcom Research & Technology and also there it has been more FOSSi work than usual, which I think is a good indication that open source silicon is becoming increasingly more common in chip design in general. The year started off by finishing up some work on SweRVolf together with a couple of my Qamcom colleagues. SweRVolf is a project under CHIPS Alliance, an organization that Qamcom has been part of since 2019 to help improve the state for open source and custom silicon. After that I was pulled into a project for doing climate research with a huge radar system. My task here was to handle sub-nanosecond time synchronization between systems located hundreds of miles from each other, using the White Rabbit system developed at CERN. I was pretty excited about getting to know White Rabbit. The timing section at CERN responsible for the White Rabbit project and associated technologies are household names within open source silicon and have a long history here. I know many of the people working there personally and have great respect for their work. But so far I  haven't had the chance until now to actually get down and dirty with the technology. Once my job was done there I moved on to another proprietary project that I can't discuss here. I do get to use FuseSoC and Verilator though, so it's fine :)

FOSSi Foundation

The hat I tend to wear most when topic revolves around open source silicon is my FOSSi Foundation director hat. And despite doing a lot less of the things we normally spend time on, it turns out we did a lot of other great things instead. I will however not go into more detail here, but instead point to the excellent summary done by my FOSSi Foundation colleague Philipp Wagner.

RISC-V

Arguably the most well-known project nowadays with ties to open source silicon is RISC-V. My RISC-V ties deepened in the beginning of the year when I was asked to become a RISC-V ambassador. Part of being an ambassador is to create awareness of RISC-V in the fields where I'm active. For well-known reasons the number and nature of events were a bit different from previous years which meant fewer opportunities to weild this new-found power, but I did participate in an ask-the-expert session during the RISC-V global forum and a couple of other events that will be described later. And I also got to be interviewed about RISC-V and open source silicon by Sweden's largest electronics and tech news outlets as well as the Architecnologia blog.



Current crop of RISC-V Ambassadors; AKA the Twantasic 12

In addition to my day job and participating in different organizations I also run a bunch of open source projects, so let's take a look at the progress of the most important ones during 2020.
 

SweRVolf

SweRVolf is an extendable and portable reference SoC platform for the Western Digital / CHIPS Alliance SweRV cores. SweRVolf is designed for software engineers who wants a turn-key system to evaluate SweRV performance and features, for system designers who want a base platform to build upon and for learners of SoC design, computer architecture, embedded systems or open source silicon methodology. To easily achieve the goals of portability and extendability it is powered by FuseSoC, which just happens to be one of my other open source silicon projects mentioned later on.

During 2020 SweRVolf gained support for booting from SPI Flash but most effort was spent on usability,  by making it rock-solid, improve documentation, increase compatibility with more EDA tools, keep the underlying cores up-to-date and follow along with changes in the Zephyr operating system, which is the officially supported software platform for SweRVolf.

But the biggest thing to happen SweRVolf this year is that SweRVolf will be used as the base of a new university course from Imagination University Programme called RVfpga: Understanding Computer Architecture. I'm very excited (and slightly scared) about soon having thousands of students getting familiar with computer architecture, RISC-V and open source silicon through a SoC that I have designed. And I would like to mention a few things about how SwerRVolf is built because I think it's a great example of how to create chip designs. When I say that I have designed SweRVolf, most of the work has consisted of putting together various pieces and make sure it works well as a whole. Most of the underlying code has been written by other people, and from my perspective, that is really the most successful aspect of SweRVolf because it highlights the rich open source silicon ecosystem. The main CPU core is from Western Digital and governed by CHIPS Alliance. Most of the AXI infrastructure was developed through the PULP project at ETH Zürich and University of Bologna. The UART and SPI controllers were developed for the OpenRISC project during the first wave of open source silicon almost 20 years ago. The Wishbone infrastructure was developed by me when I started out with open source silicon ten years ago and the memory controller was created by Enjoy Digital and is written in Migen as part of the Litex ecosystem. And to go full circle, the memory controller uses a tiny RISC-V CPU called SERV internally to aid with calibration. SERV, the world's smallest RISC-V CPU is written by me. Small world. And of course the whole project is packaged with FuseSoC and uses Verilator by default for simulations, so it's FOSSi all the way. As I hope you understand by now it's not about some lone hero churning out code, but instead all this has been made possible by a huge amount of work by a ton of people over many years, and I'm proud to be one of them.


SERV

Probably the hobby (read unpaid) project I spent most time on during 2020 was SERV, the world's smallest RISC-V CPU, which turned from small to even smaller during the year. SERV is very much a project driven by numbers, so lets look at some of these numbers.

In February I got hold of an ZCU106 development board with a huge Xilinx Ultrascale+ FPGA for a project I was assigned to. As this was the largest FPGA I had ever had in my home I got curious to see how many SERV cores I could squeeze into it. The year before, at the 2019 RISC-V workshop in Zürich, I had done a presentation on how to fit 8 RISC-V cores in a small Lattice iCE40 FPGA (spoiler: it ended up being slightly more than 8 eventually), giving each of them a single I/O to communicate with the outside world. Problem this time was that after stuffing in 360 cores I run out of I/O pins. It would also had been practically impossible to verify that all these external pins actually did what they were supposed to do, so I needed some way of using less than one I/O pin per core. Then it struck me that just a few months earlier I had created a heterogenous sensor aggregation platform based on SERV cores called Observer. The idea with Observer was to connect a lot of sensors to an FPGA, each serviced by its own SERV core and then merge the data to an output stream. I gave up on the platform when I realized that while I could fit a lot of SERV cores into the devices, I just had a few sensors so there wasn't much data to to aggregate. But this platform was a very good starting point.

Block diagram of the Observer platform
By removing all sensor interfaces and just have each core print out an identification message instead I had a system that I could instantiate with any number of cores. Trying this on the ZCU106 I could now run over 600 cores on the FPGA. The next problem then was that I was running out of on-chip RAM way before any of the other FPGA resources. In case you don't know, most FPGAs contain a number of fixed-size SRAM spread out over the devices, each typically being 1-8kB large. For SERV, each core used one for the RF (register file), and another one for the program/data memory. With RISC-V using 32 32-bit registers, this means that only 128 bytes of the RF RAM is used but since the fixed-size SRAM on FPGAs are typically being far larger than that most of the RAM ends up unused. That's bad, but I had a plan. With a bit of work I managed to share RF, program and data in the same RAM so that the RF is allocated to the top 128 bytes of the RAM. This freed up half of the on-chip RAM blocks and I could eventually hit 1000 SERV cores on the ZCU106 board. Of course, at this point I was curious to see what the situation was for other boards after all these optimizations. Taking it one step further I figured I should turn this into a real thing by creating a benchmark so that people can have a quick way to see roughly how large the FPGAs are on different boards. And with that ServMark was born.


 

 ServMark lasted for about three minutes until I realized CoreScore was a much catchier name, so that's we have now.

 

I had originally planned to do a presentation about SERV at Latch-Up in Boston. But for well-known reasons we cancelled all FOSSi Foundation physical events. Instead I accepted an invitation to speak at the First virtual RISC-V Munich meetup. By this point I had attended a couple of virtual meetups and I hated it. It was in most cases awful to watch a narrated slide deck without a stage and a speaker to bring it to life at least a bit. So, I decided to take a fresh look and look at the possibilities instead of being limited by the medium. I decided to make videos instead. First of all, since people would watch on a computer screen with proper resolution instead of a washed-out image projected on canvas. This meant I could have much more detailed pictures and smaller font sizes. I could also freely mix pictures and animations, fine-tune timings, do several takes of the audio and add sound effects. And despite being done by someone who has pretty much zero experience in these sort of things, I think it turned out pretty well. So on the day of the event, I just introduced myself and let the audience indulge in my fully immersive multimedia edutainment experience about SERV. Not sure why the Oscars committee hasn't got in touch yet.

Is CoreScore the only attempt to put a mind-boggling number of RISC-V cores inside chips? Absolutely not, and during the summer I learned of the Manticore project from Florian Zaruba and Fabian Schuiki (jointly known as Flobian Schuba) from ETH Zürich, both well-known names in the FOSSisphere from their work in the PULP ecosystem. Manticore: A 4096-core RISC-V Chiplet Architecture for Ultra-efficient Floating-point Computing had been accepted into the prestigious Hot chips conference. Manticore is an impressive project, but I still thought it was a bit unfair that I wasn't invited as well. So I reached out for the biggest FPGA board I could find and then wrote my first academic paper of the year called Plenticore: A 4097-core RISC-V SoClet Architecture for Ultra-inefficient Floating-point Computing. Unfortunately I did not recieve an invitation to Hot chips despite this. I assume it must have gotten lost in the mail somewhere.

Oh well, let's look at some more numbers instead.

  • A number of optimizations was found over the year which, depending on the measure, further shrank the core 5-10%.

  • The number of supported FPGA boards for the servant SoC grew from 4 to 17, mostly thanks to other contributors (thanks everyone, love you all!)
     
  • The SERV support for the Zephyr operating system was rewritten and upgraded from the aging Zephyr 1.13 to 2.4, the latest version at the time of writing.


SERV resource usage over time on a Lattice iCE40 FPGA

 

Coming back to CoreScore, the results right now range from 10 cores on a smaller Lattice iCE40 device up to 5087 cores on a large Xilinx device and the high score table can even be viewed interactively online! If you can't find your favorite board there, just send a PR and we'll get it added. And if any people with access to crazy large FPGAs happen to read this, please get in touch with me. I'm very curious to see who will be first to get above 10000 cores.

SERV also saw another great improvement in the form of documentation. While not completely there yet, the functionality of most SERV modules have been documented together with detailed schematics showing the implementation down the individual gates, muxes and flip-flops. And most changes to the source are now accompanied by a code comment to clarify what is going on. Since SERV is optimized for size rather than readability, many parts of the core are difficult to figure out by just looking at the source code. Hopefully this will make it easier for other who want to understand or work on the core, but frankly it has also been very useful for me since I tend to forget why I did things in a certain way so I have had to spend a lot of time following my own tracks.

Schematic of the SERV control unit from the SERV documentation


FuseSoC

The oldest of my open source silicon project still going strong is FuseSoC. It is now about to turn ten years old and keeps growing in features and users for each year. Looking back at the changes through 2020 I can see some new trends in the development. The most important one is that for the first year ever, most of the work was not done by me. During 2020, my fellow FOSSi Foundation director and LowRISC employee Philipp Wagner has been pulling the heaviest load of FuseSoC development. And with Philipp came quality. Dr. Wagner has improved FuseSoC in pretty much every aspect. Bugs have been fixed and features has been added. The development experience has been improved by CI testing, automatic code formatting checks and improved testing coverage. And what makes me happiest is that the user experience has been improved not least by a total rewrite of the documentation into something that is actually useful and can be proudly shown to the world. All this is very much needed as FuseSoC is becoming increasingly popular. It has already been picked up by many of the flagship open source silicon projects like OpenTitan, SweRVolf, OpenPiton and with the RVFPGA university programme there will soon be a whole new generation who will get familiar with it as well.

Edalize

In 2018, the part of FuseSoC that interacted with the EDA tools was spun off into Edalize. The reason was that it was believed this part could be useful for others who weren't interested in the whole FuseSoC package. This prediction seems to have been correct and Edalize has very much started a life on its own by now. In addition to FuseSoC, Edalize is now used by several other projects such as Silice, Clash and fpga-perf-tool and over the year Edalize has gained support for 7 new EDA tool flows, bringing the total number up to 25.

2020 was also the year when Edalize had it's first taste of being in the spotlight on its own merits. For the Workshop on Open-Source EDA Technology (WOSET) 2020 I decided to submit a presentation about Edalize. Being an academic conference this also prompted me to write an accompanying paper as is the common courtesy for these kind of events. The paper received a lukewarm response but was accepted anyway. Once again I did not feel like reciting slides to a camera so I turned back to my new-found interest in advanced multimedia productions. And it paid off. The Edalize video won an award for best video at WOSET 2020. Well done Edalize!

LED to Believe

All of the above projects use FuseSoC and Edalize because - well it's kind of why I created FuseSoC in the first place - to easily reuse components and retarget to different devices. But I also realized there was a need for a dead simple project to help people getting started with FuseSoC - the Hello world of silicon, so to speak. And the Hello World of silicon is of course the blinking LED. So in 2018 I created project LED to Believe with the ambitious goal to create FuseSoC-powered LED blinkers for every FPGA board ever made. The project has several aspects that are useful in different ways. It serves as a very simple introduction to FuseSoC and how to make a design that targets multiple hardware. It is also an excellent pipe cleaner for when you receive a new board. If you can run the project successfully and get the LED to blink, it likely means you have managed to install all the EDA tools correctly which is no small feat, and you also have a template to take on bigger projects. And it's also fun to see what boards are available out there. While I have submitted a bunch of the board ports myself, the vast majority have come from all the fantastic contributors out there. And during 2020 the number of supported boards grew from 16 to 44. Perhaps not all the FPGA boards ever made, but a considerable chunk of them. And already in the short amount of 2021 that has passed, there have been numerous more contributions so we're getting closer all the time.



In closing, 2020 was a busy year FOSSi-wise. And this has just touched upon the surface of all things that have been happening during the year. And just as we were about to close the books on 2020, I was informed that Lattice had incorporated one of my FOSSi projects into their shiny new award-winning Propel design suite. Which project, you might ask? Was it the similarly award-winning FuseSoC, to give Lattice users immediate access to a rich ecosystem of Open IP cores? Or was it the Rosetta stone of Edalize, with its award-winning video, that would easily provide a coherent interface for a dozen simulators and make it easy to switch between Lattice's multitude of FPGA tools such as Diamond, icecube2 and Radiant? Or was it SERV itself, the award-winning CPU capable of offering a RISC-V experience for all but their absolutely smallest offerings? Well, actually, none of the above. It turns out that Propel now contains ipyxact, my somewhat feature-limited Python library for working with IP-XACT files. Not my first choice, but fair enough. I wonder if they have read my somewhat complicated relationship with IP-XACT.

Finally my work is recognized by big EDA vendors (picture by Gatecat)

 



tisdag 10 december 2019

2019 : A year of RISC-V and Open source silicon

Note: This article was originally posted on LinkedIn in December 2019 and was later posted on this blog with a backdated publishing date

I will unfortunately not make it to the RISC-V summit this year, but since everyone will be talking about RISC-V this coming week I thought it would be a good opportunity to highlight some of the work I have done this year within RISC-V and FOSSi (Free and open source silicon) in general. And you are more than welcome to contact me if you are interested in knowing more about any of this work or other things related to RISC-V, FOSSi or Qamcom

SweRVolf

Western Digital made a big splash last year when they announced the release of the open source RISC-V CPU SweRV EH1, currently the fastest 32-bit RISC-V CPU available. Together with Western Digital I have created SwerRVolf, an open source portable and extendible SoC using the SweRV EH1. The intention with this SoC is to allow users interested in SweRV to quickly get started running software or building their own customized SoC using SweRV. The whole project is open source and can be run in a simulator or on supported FPGA targets. On the software side it can be used to run Zephyr OS and has debugging support. The code is available at https://github.com/chipsalliance/Cores-SweRVolf More features will come in 2020 so make sure to check in regularily. The project has also been featured in presentations at the inagural CHIPS Alliance workshop as well as the CHIPS Alliance tools November workshop in Munich. During the latter there was also a tutorial aimed to get people started using the SoC. This workshop is also freely available and I'm happy to do variations on this within your company if you want to get started with a RISC-V SoC.

SERV

In case you're not aware, I have created SERV, likely the world's smallest RISC-V CPU and still cabable of running Zephyr OS. SERV was originally created for the 2018 RISC-V SoftCPU contest, but I have kept working on the core during 2019. In April I submitted a presentation for the RISC-V workshop in Zürich called "Bit by bit - how to fit 8 RISC-V cores on a $38 FPGA board". When there was time to do the actual presentation I had to update the title since further optimizations had allowed me to fit 16 cores on the same board. Work continued after that and in November I was able to fit 53 RISC-V cores on a $30 FPGA board. The SERV CPU is of course open source and available here https://github.com/olofk/serv If you want to learn how to build SERV into your designs and why you should do it, just reach out and I'll get you up to speed.

FuseSoC

FuseSoC is a package manager for IP cores. It is created to manage and describe collections of open source and proprietary cores so that they can be put together to make a SoC. FuseSoC has been around for eight years now, but the past year has seen a lot of improvements and a massive growth of available IP cores (over 500 cores!) to use with FuseSoC. This year it has also been adopted by some major Open source silicon projects such as the manycore OpenPiton project from from Princeton and OpenTitan, the industry collaboration project to create a fully open source Root of Trust device. Even though there are a large number of RISC-V based projects using FuseSoC it is used in many places as well, most notably this year is perhaps the open source POWER implementation called MicroWatt released this summer. If you want help with packaging your RISC-V core to be available for FuseSoC users or if you want to use FuseSoC within your company to manage your IP cores, just let me know. FuseSoC can be found here https://github.com/olofk/fusesoc

Edalize

Closely related to FuseSoC is Edalize, which originally was part of FuseSoC but now a project of its own. Edalize is a build tool abstraction which provides a common interface to the supported EDA tools. It can be used to e.g. target different simulators with a flick of a switch or easily run the same design on FPGA and simulation targets. This year has seen many improvements and support for three new tool flows, which brings up the number of supported tools to 17. Most of this work has been done by contributors, which is a great indicator that it is actively used by many people. See more here https://github.com/olofk/edalize If you're a user or a tool vendor and feel that your favorite tool is missing, just let me know and we can discuss how to add it.

Observer

By combining the flexibility of FuseSoC with the resource efficiency of SERV I created a project called Observer. Observer is a software-programmable sensor aggregation platform for heterogenous sensors, combining the best of HW and SW in an FPGA. It is built on the idea that FPGAs are excellent for communicating with various types of external devices, but many types of data processing are best done in software. By pairing a SERV CPU to each sensor it is possible to combine the speed of RTL with the flexibility of software to easily build a sensor fusion system. The project is still in early stages, but works on a supported FPGA platform already and as a proof of concept it has been shown possible to collect data from over 50 different sensors simultaneously, each with their dedicated RISC-V CPU to handle data. Code can be found here https://github.com/olofk/observer If you want to customize Observer for your particular use case I'm happy to talk more.

Qamcom joins RISC-V Foundation

This year Qamcom joined the RISC-V Foundation. As our first exercise upon joing the foundation, we teamed up with RISC-V veterans SiFive to host the SiFive Tech Symposium in Stockholm in May. At this event we highlighted how we see that RISC-V can benefit many of the areas where we provide expert knowledge, such as AI, automotive, RADAR and 5G. If you are interested in what services Qamcom can provide within these areas and other, feel free to contact me or any of my colleagues or read more about us on https://www.qamcom.se/

Qamcom joins CHIPS Alliance

RISC-V is getting a lot of attention, but an open source ISA is just one of the many challenges we are facing when it comes to innovating chip design. We see an increasing need for custom silicon for many of our clients and partners and there are many keys to unlock to achieve this. CHIPS Alliance is an important consortium with a combination of small and large forward-thinking companies that aims to make open source silicon viable by collaborating on common cores, tools and infrastructure. If you want to be part of the CHIPS Alliance to accelerate chip design, go to https://chipsalliance.org/ to learn more.

Qamcom joins Mentor OpenDoor

Mentor, a Siemens business, has a partner program called OpenDoor. Both Mentor and Qamcom sees the importance of high quality verification of open source silicon and by joining this program, we will ensure that the work we do within open source silicon has first-class support for Mentor's EDA tools to allow new and existing users of these tools to quickly get started using open source IP cores in their products.

FOSSi Foundation

In 2015 I co-founded the FOSSi Foundation with a mission to promote and assist open source silicon in the industry, academia and for hobbyists. FOSSi Foundation consists of many people who work across all levels to acheive these goals but my personal involvement this year has mostly focused on creating events to bring people from industry, academia and hobbyists together under a single roof to exchange experiences. As usual we had ORConf in Europe but we also teamed up with the RISC-V Foundation to create the Week of Open Source Hardware (WOSH) in Zürich conjoined with the RISC-V workshop there. During the event I presented SERV, a poster of FuseSoC and won an award for FuseSoC given by Eurolab4HPC. This was also the year when we did our first conference on US soil. In May we held a new event called Latch-Up in Portland, Oregeon which was a great sucesss. We are already planning for three events next year as well. First up is FOSSiStanbul in Istanbul, Turkey, followed by a new Latch-Up in Cambridge, MA and the usual ORConf some time in the fall. Check out https://fossi-foundation.org/events to see where you should book your tickets.

Apart from events I was also mentor for Google Summer of Code for the fourth year in a row. This year I co-mentored Nancy Chauhan who worked with FOSSi Foundation and did a fantastic job to improve our CI platform at ci.librecores.org

Other stuff

I have had a long and troubling relationship with IP-XACT, as can be seen in my most cited article  . I still stand by my point that we need some sort of standard for describing many of the aspects of IP cores that FuseSoC doesn't care about such as register maps and how to connect cores to each other. I haven't done much work in this area for a long time, but a presentation at Latch-Up by Aliaksei Chapyzhenka on a project called DuH prompted me to resume my efforts and I have now started working on combined IP-XACT/Duh tooling that I hope will be of interest. It's of course open source as well, but I haven't cleaned up enough to release it yet :) If you are an IP-XACT user or interested in tooling in this area, please let me know.

Wow! This turned out far longer than I expected. Seem I did a lot of stuff around RISC-V and Open source silicon in 2019. Let's see what the next decade will bring

Catch up at Latch-Up!

 

 

 

 

 

tisdag 26 juni 2018

FuseSoC 1.8.2

FuseSoC 1.9 will have an impact so great that people will divide history into the eras before and after it's release. But before that happens, it's time for a less earth-shattering minor release. Allow me to introduce FuseSoC 1.8.2

Backend separation

The biggest feature is also the least visible for most users. A lot of time since the last release was spent on moving stuff around with the ultimate goal of splitting out the backends (the part that create project files and launches EDA tools) to a separate library. This is now complete and the former backend code now lives in a separate library called edalize, which remains part of FuseSoC for now, but will be moved out at some point. The ideas behind this will be a topic for a separate article at some point, but if you're building some Python tool that wants to use the EDA tool wrappers, look for edalize now.

Linter backends

FuseSoC.. sorry, Edalize has gained a new backend for Synopsys SpyGlass which is a powerful linter tool. For a less costly linter, it is now possible also to use the linter mode of Verilator by setting mode to lint-only in the verilator section of the tool options in a target like this

targets:
  lint:
    tools:
      verilator:
        mode: lint-only

CAPI2 changes

The latest core description format has had some minor improvements. The top-level option was originally specified as a list of modules. since there are cases when several top-modules are needed. This however is quite rare, which makes it confusing that it's just a list of one item in most cases. Therefore it can now also be specified as a string. Small improvement, but makes things less annoying. Environment variables are also expanded in file names.

Other changes

Sometimes you really want to ignore a core that's part of a library. By adding a file called FUSESOC_IGNORE to a directory, FuseSoC will ignore that directory and everything below it. There is also a series of tutorials in the works. These are very rough drafts at this point, but I encourage everyone who wants to get started with FuseSoC to take a look through them anyway. They are located here

That's pretty much it. As usual, a number of bugs were fixed but nothing worth taking up more of your precious time. Thank you for reading. See you again in the post FuseSoC 1.9 era

torsdag 22 mars 2018

FuseSoC 1.8.1

With great features come great bugs. FuseSoC 1.8 had a lot of new functionality but it also has some shortcomings. Some of it was intentional. For both the library support and CAPI2 I wanted to push out an early version with the most important functionality, test the waters and add the missing pieces later. (Un)fortunately both these features turned out to be really really good and I came to depend on them immediately. This made it more important to make sure they were useful as I don't want to use the old ways anymore. After some post-release patching I'd say things are in much better shape, so it made sense to do a new release with these things fixed. Therefore I present FuseSoC 1.8.1. It's like 1.8, just a little better.

What's changed then?

Library fixes

The library sections in fusesoc.conf has gained a sync-type flag. This allows users to explictly set what mechanism to use for synchronizing libraries against a remote source (e.g. updating). The only two current values are git, which does a git pull of the library when running fusesoc update, and local, which won't try to synchronize at all. The library sync-type options share code with the core providers, so it should be easy to add other synchronization mechanisms (e.g. rsync, webdav, mercurial) when needed. When adding a new library there is also now a --global flag. If this is present, the library will be added to the user-global fusesoc.conf in $XDG_CONFIG_HOME/fusesoc. Otherwise, a fusesoc.conf in the current workspace directory will be used.

CAPI2 fixes

CAPI2 debuted with support for just a few tools. This was a trade-off to be able to do a quick release. Of course, it soon became apparent that the other tools were needed as well. One other thing that bothered me with CAPI2 was that the tools sections were a hard-coded list in the core class. So to fix both these things at the same  time I did some refactoring and let the backends themselves declare which options they use. FuseSoC will then search for available backends at run time and pick up their available tool options. Voilà, all tools are now supported in CAPI2. This also opens up for more easily adding new tool backends without having to change anything else in the code base.

There are more things missing in CAPI2, but the one that I realized was needed most was the equivalent of the scripts section in CAPI1. I took the opportunity to rearrange things slightly so that I could make this more powerful than in CAPI1. Instead of a list of shell scripts to run, it is now possible to launch arbitrary commands and associate extra files to be exported to the work root and environment variables to be set.

Other fixes

Other noteworthy things that are added to FuseSoC 1.8.1 is a bash completion script that was contributed almost four years ago but never merged. This was polished up by another contributor and is now available in the extras directory of the FuseSoC repo. It is not installed by default, but has to be copied into the appropriate directory (e.g. /etc/bash_completion.d on my system).

Finally, FuseSoC no longer writes a fusesoc.log by default. Writing this logfile on every run has annoyed me for almost six years now, but I never got around to fix it. Thankfully there are other contributors who get things done.

And that's all. Hope you like it!

måndag 5 februari 2018

FuseSoC 1.8

Too tired to write something clever here. Just get it over with. Stuff has changed. Here's what's new

CAPI2

The main feature of FuseSoC 1.8 is the support for a new core description format, CAPI2, to replace the old CAPI1 format. The need for a new format to solve support some use cases has been apparent for a while. Doing some archaeology I found a commit from March 2, 2013 that mentions the next generation format, and yes, after careful evalutation of a few different formats it ended up being based on YAML. Oh well, things take time and there have been other priorities. At least it's here now, or rather, a first experimental version. The CAPI2 support in FuseSoC 1.8 still has many missing features, like documentation and support for IP-XACT and all tools to name a few. There might also be non-compatible changes ahead, but I want to push it out now together with some CAPI2 cores to reach a wider audience.

So what's so good about CAPI2? I'm hoping to find the time to write a separate article with more details some time in the future, but I have written down some of the benefits.

New tool flows

Support for other tool types than simulators and synthesis tools. This includes things like formal verification tools and linters. For linting, I have already made a quick PoC using Verilator in lint mode and there is a Spyglass backend in the works. On the formal verification side, I will start to look into what's need to add support for Yosys-SMTBMC  

Multiple targets

With the support for new flows for a design there is also a need to decide which flow to use. For this, CAPI2 supports multiple targets in a single core file. There are many uses for different targets. A design might have several testbenches that exercises different parts of the design.  These can be specified as different targets using different source files, run time parameters, tool options etc. Some designs have support for targeting multiple FPGA boards. These can also be described as separate targets, with the benefit that they can share all the common parts while freely add target-specific files and options. Targets for linting or formal verification can be separate targets as well.

Conditional expressions

CAPI2 contains a minimal expression parser inspired by the Gentoo ebuild format. An expression can look something like this


flag? (use_if_flag_is_true)
!flag? (use_if_flag_is_false)

This allows including or excluding features depending on which tool is being used or whether the core is at the root of the dependency hierarchy or being used as a dependency for another core. Examples of this can be to enable technology-specific RTL primitives for certain tools, switch between VPI or DPI extensions depending on tool support or use a C++ testbench for verilator while other simulators use a non-synthesisable verilog version. At the time of writing, these flags are defined internally in FuseSoC depending on current tool, target and some other parameters, but it will be possible in the near future for users to define their own flags and set them in the top-level core file or on the command-line.

 Core libraries

FuseSoC already has the ability to define directory paths which contain core files, either by specifying them with the cores_root option in fusesoc.conf, on the command-line with --cores-root= or through the FUSESOC_CORES environment variable. This is all good, but a bit limited. With FuseSoC 1.8 comes support for core libraries. Each library is specified in fusesoc.conf as a separate section. An equivalent of an old config file looking like this


[main]
cores_root = /home/user/.local/share/fusesoc/orpsoc-cores /home/user/cores/fusesoc-cores


will now look like this


[library.orpsoc-cores]

[library.fusesoc-cores]
location = /home/user/cores/fusesoc-cores

So far there isn't much of an improvement over the old style. One thing to notice is that if the location option is missing, it will default to $XDG_DATA_HOME/fusesoc/<library name>

Having separate sections however also allow us to do the following


[library.orpsoc-cores]
sync-uri = https://github.com/openrisc/orpsoc-cores

[library.fusesoc-cores]
location = /home/user/cores/fusesoc-cores
sync-uri = https://github.com/fusesoc/fusesoc-cores
auto-sync = false

sync-uri lets us to specify the remote source of a library. The initial supported remote location are git repositories, but other source such as mercurial, rsync, webdav etc will be support with a sync-type option in the future. The auto-sync option, which defaults to true, controls if the library shall be updated when running fusesoc update.The update command can also take a list of libraries as extra argument to selectively update libraries.

To support library management from the command-line, FuseSoC has now gained a new library subcommand. The only supported library command is currently add, to register a new library, but additional commands for listing and removing libraries will be added in time. To add a remote library, the following commands can be used


fusesoc add library enigma https://github.com/mmicko/enigmaFPGA

The resulting fusesoc.conf will look like this


[library.orpsoc-cores]
sync-uri = https://github.com/openrisc/orpsoc-cores

[library.fusesoc-cores]
location = /home/user/cores/fusesoc-cores
sync-uri = https://github.com/fusesoc/fusesoc-cores
auto-sync = false

[library.enigma]
sync-uri = https://github.com/mmicko/enigmaFPGA 


There are also optional arguments --location and --no-auto-sync to explicitly set the location and auto-sync = false

For adding a directory path as a library, the same command is used, but the sync-uri is treated as a location if FuseSoC detects that it's an existing directory


$ fusesoc library add more_cores ~/other_cores
INFO: Detecting /home/user/other_cores as a local library

will produce


[library.orpsoc-cores]
sync-uri = https://github.com/openrisc/orpsoc-cores

[library.fusesoc-cores]
location = /home/user/cores/fusesoc-cores
sync-uri = https://github.com/fusesoc/fusesoc-cores
auto-sync = false

[library.enigma]
sync-uri = https://github.com/mmicko/enigmaFPGA 

[library.more_cores]
location = /home/user/other_cores

There are more planned featues for core libraries, but this will have to do for today.

Backend features


Most of the tool backends have received fixes or new features. All tools now supports file type = user for passing arbitrary files to the build tree that might be neeeded by the tools. For Xilinx ISE, FuseSoC now supports BMM files as an allowed file type and quoting of verilog string parameters should now work. Isim will shut down properly after simulations, GHDL will receive its arguments in the correct order and XSim supports multiple top-levels. The IceStorm backend now supports verilog defines specified as command-line parameters, has gotten a yosys_synth_options parameters to set extra synthesis options and PCF constraint files are recognized as a file type

Other things

Other things worth mentioning are the new --no-export feature. Before an EDA tool is invoked, FuseSoC has always created a fresh build tree where it places all files and runs the EDA tools to avoid polluting the source directories with files and to not pick up unwanted files that might be lying around in the source trees. This also has the added benefit that the exported build tree is not dependent on FuseSoC and can be archived or sent to non-FuseSoC users if required. I have used that myself to make deliveries of projects to clients. There are however cases where this is not optimal, for example during debugging, when there is a need to make small changes to a file in the source tree without having to recreate the build tree every time. For such use-cases FuseSoC now supports a --no-export option that will reference the original source files instead of copying them to the build tree. For most cases, this should work just as fine, but beware that it might break in some situations, e.g. when multiple cores has an include file with the same name.

Another improvement related to coping files around is a new copyto attribute for files in filesets. It's used like this:


[fileset fs]
files = an/old/file.v[copyto=a/new/name.v]

or with CAPI2, like this

filesets:
  fs:
    files:
      - an/old/file.v: {copyto : a/new/name.v}

This will copy the file to a new location, relative to the work root of the EDA tool and reference this version in the EDA API file. This is quite useful in several situations, for example when a file is required to exist in the working directory. Previously this had to be done with a pre_build_script to copy the file, which also had the disadvantage of being platform-specific. It also makes it less awkward to reference files from the source directory in verilog parameters. For example the top-level of the de0_nano system in orpsoc-cores contain bootrom_file = "../src/de0_nano_0/sw/spi_uimage_loader.vh", which a) assumes source code tree is located in ../src and b) has to be updated on version bumps when the de0_nano_0 name will change. This can now be replaced with bootrom_file = spi_uimage_loader.vh and a copyto = spi_uimage_loader.vh in the .core file. Much better!
 
EDA API - the tool-agnostic file format which is used to pass all information needed by the backends such as the list of files to read and tool options - has seen some changes and will continue to do so in the future. For this reason, it has gained a version field so that external projects which want to read EDA API files will know what to expect in the file. Properly formalizing the EDA API is still a task at hand, but is getting more prioritized now as there are external projects interested in using this format so that they can reuse either the FuseSoC core files and dependency handler or the EDA tool wrappers. This means it's pretty rude to make arbitrary changes to the format without at least informing about it.

There are also some new commands and switches for the FuseSoC 1.8 release. Before CAPI2 you would either build an FPGA image or sim a simulation. Wiht the sight set on new tool types, none of these commands really describe what you do when you run an linter. So there is now a command called run. Going forward, this will be the main command to use when launching EDA tools through FuseSoC. The run command currently has switches for setting the desired target and tool, and can run any of the tree stages setup, build and run. Without any stages being explicitly set it will run them all. The tool can also be derived from the core description in many cases. build and sim will remain as special cases of run for the time being. sim will be the equivalent of run --target=sim and build will evaluate to run --target=sim --setup --build. The build command has also gained --tool and --target switches for overriding the default options. As for new switches, it is now possible to explicitly point out a FuseSoC config file to use with the --config option

That's all folks. Hope you like it. Please try it out and send me patches, bug reports or perfumed letters if you find anything you like or want to see improved.

See you later, Verilator
In a while, Synplify