2018.1 Release: Linux, Debugging, Automation, and Tons of Fixes

Woohoo! After more than two years of work and 479 git commits later we are very proud to present the all-new 2018.1 release of OpTiMSoC! A look at the statistics gives a first impression of how large this release is: diffstat tells us about 973 files changed, 133,697 lines inserted and 58,806 lines deleted. Or in other words, the code size increased by 74,891 lines! How do those lines of code translate into functionality, you may ask? Let’s have a closer look.

Debug Infrastructure

The debug infrastructure of OpTiMSoC is essential in getting code running on the system, in debugging it, and in performing measurements. Over the last year we have fully re-implemented the host software of the debug system as part of Open SoC Debug (OSD), and imported it back into OpTiMSoC. Together with this rewrite we extended and improved the OSD specification document to be even more complete, flexible, and robust.

Other changes:

• A rock-solid off-chip interface is key: if developers cannot reliably access the SoC frustration levels can rise quickly. To avoid that, Max significantly improved the UART and USB3 (Cypress FX3) backends of GLIP, which provide the off-chip interface for OSD and consequently for OpTiMSoC.
• The implementation of the off-chip interfaces are now free of vendor primitives, making the porting between FPGAs easier than ever.
• New and improved Python bindings make it easy to interact with an OpTiMSoC system in an automated way.
• Last but not least, a new implementation of the UART Device Emulation Module within Open SoC Debug by Thomas Leyk was the last remaining blocker to get Linux up and running on OpTiMSoC.

Refreshed Network on Chip (NoC) Implementation

In previous generations of OpTiMSoC we relied on a NoC implementation called LISNoC. Developed as part of a research project a couple years ago it has shown its age in various places. Stefan took up the job of reimplementing significant parts of it, leading to a design which is easier to understand and more flexible as a result.

Testing and Automation

OpTiMSoC is complex: hardware, software, tooling, all need to work together to form a feature-rich System on Chip. To ensure that we don’t accidentally break functionality we have added more tests on various levels. The tests can be executed manually by every developer, and are executed automatically: some on every check-in, some once a day.

• Static analysis helps to catch bugs early. For hardware, we are making use of Spyglass Lint to check the code for common errors.
• To test and verify the functionality of our hardware modules, we have added more cocotb tests to the tree.
• All software imported from Open SoC Debug is tested extensively with unit tests and static analysis tools to avoid regressions and to catch bugs like memory leaks early. Look at the configuration in the opensocdebug/osd-sw repository for more details.
• All steps in the tutorial within the user guide are now covered by automated tests. Even the tutorial showing how to build and flash Linux on an OpTiMSoC system running on an FPGA is fully performed and checked as part of a test. This allows us to say: our tutorials always work!
• Finally, we have fully automated our test and build infrastructure using Travis (directly visible on GitHub) and GitLab CI (for nightly builds using internal infrastructure). Read more about that in a separate blog post.

User Experience

OpTiMSoC is used at TUM for research and teaching purposes. With many different people working on it it is essential to provide a great out-of-the-box user experience. Many small changes in this regard accumulated over the period of this release.

• The steps needed to get started with OpTiMSoC have been reduced. For example, all dependencies can be now installed with a single script.
• A new tool, optimsoc-pgm-fpga, has been added to help flashing a bitstream onto an FPGA.
• Initially we shipped our own version of FuseSoC. Now that all of our patches have made it upstream we were able to rely on the upstream version, which is easily installable through pip.
• Good documentation makes a developer’s life so much easier. This time around we added API documentation for our SoC software libraries, documented the NoC implementation, and added a guide how to port OpTiMSoC to new FPGAs.
• It might seem like a odd entry in the category “user experience,” but it is an important one: we integrated a fan controller for the VCU108 board, significantly reducing the noise level produced by this board.
• Finally, we added a script to automatically install an Eclipse IDE with all recommended settings to develop with and on OpTiMSoC.

Linux Support

Most users of OpTiMSoC run baremetal software on it, i.e. programming it like a microcontroller without any operating system. Supporting advanced operating systems has always been a dream, but getting there required a lot of work. But with all the small and large changes in this release and in the previous releases, we finally were able to make our dream come true: reliably boot Linux on OpTiMSoC. Partly responsible for this dream is also the work of Stafford Horne, who worked relentlessly to update the OpenRISC port of Linux upstream and to incorporate all the changes that accumulated over the years.

Read more about that in Linux on OpTiMSoC: How many small steps unlock a whole new world.

Contributors

This release would not have happened without the continued great work of our contributors. In this release the following people contributed.

• Shivam Aggarwal
• Franz Biersack
• Annika Fuchs
• Max Koenen
• Pedro H. Penna
• Philipp Wagner
• Stefan Wallentowitz