El Correo Libre Issue 36

Published in

LibreCores

14 min readMar 9, 2021

45 Chips in 30 Days — Open-Source ASIC at its Best

Only seven months ago, open source chips were a dream of some, and clearly impossible to others. Today we know better. In a joint effort between efabless, Google, and the SkyWater foundry, everybody got a chance to send an open source chip to fabrication. And many did!

One of the key people who made all of that happen is Mohamed Kassem, co-founder and CEO of efabless. He joined us at FOSSi Dial-Up to discuss how the “Open MPW” program went so far. (A recording of the talk is available on YouTube.)

Efabless wants to enable everyone to produce chips. As previous talks in the FOSSi Dial-Up series have shown, getting to this point requires solving a huge amount of technical, legal, and financial challenges. Taken together they made it unthinkable for hobbyists, many in academia, and even for small companies to produce their own chips. Thankfully these initial hurdles are of the past. Once the innovative power of the open source community was unleashed, many of the projects associated with the Open MPW shuttle saw an exponential rise in interest.

With interest exploding there was a lot to learn for everybody involved. Efabless, Google, and SkyWater prepared for that even before the Open MPW program was announced by producing three test chips, which were intended to validate the tooling and especially the SRAM components of the chip. An experience that paid off when they put together the Caravel Harness SoC, a “frame” with a 10mm² space in the middle for the actual chip design.

The Caravel harness consists, among other things, of a PicoRV32 RISC-V CPU core, a logic analyser, DFT logic, and redundant memories of one kilobyte each. One memory is built out of SRAM cells, the other one out of regular flip-flops. Providing such redundancy within the design, is a good practice that everyone should follow to reduce risk, as Mohamed pointed out. “Allow different ways for the chip to function.”

With the Caravel harness ready, the call to submit designs closed on November 30, 2020. The response was overwhelming. 45 designs were submitted, from which 40 were selected for the run. Even more overwhelming: 60 percent of the designs were done by first-time designers, powerfully proving the fact that chip design has truly come to the point where everyone can create their own chip.

A look at the designs that were taped out shows how diverse the motivation for producing a chip can be: open processor cores, whole Systems-on-Chip, a crypto-currency miner, a robotic app processor, an amateur satellite radio transceiver, analogue, RF and embedded FPGA projects were all included.

Currently, these chip designs are being manufactured, with the 50 chips, packaged and some even on a circuit board, expected to return to their creators around the end of June. Around the same time the second fabrication round will kick off, with another one likely in December this year.

In the meantime, there is a lot to learn to better understand the fabrication process, the tooling, and how the community can come together to build open source chips. “I want to thank everyone involved in this process,” said Mohamed. “It is a continuous process that is going strong, we learn continuously from the community. It is for the first time in my life in the semiconductor industry that I have seen this level of engagement.”

To join this effort, a good starting point is the Slack channel, and the Open MPW overview page on the efabless web site.

The FOSSi Dial-Up series of talks will feature more in-depth looks at the designs that were part of the first Open MPW run, as well as other interesting topics around free and open source silicon. Head over to the Dial-Up web site for an up-to-date list of talks, and subscribe to the monthly newsletter of the FOSSi Foundation, El Correo Libre.

-The FOSSi Foundation Board of Directors

Olof Kindgren Highlights the Milestones of 2020’s “FOSSi Fever”

Free and Open Source Silicon Foundation (FOSSi Foundation) director Olof Kindgren has published a retrospective looking at some of the biggest happenings in the field over the last year — including the Open MPW Shuttle Programme.

“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,” Olof writes. “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.”

Other milestones for the year highlighted by Olof include QuickLogic’s EOS S3 system-on-chip and its embedded FPGA (eFPGA) as “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 the first toolchain that is supported and funded by the vendor rather than being at best tolerated by them,” Olof’s work at Qamcom on the SweRVolf core and CERN’s White Rabbit system, the RISC-V Ambassador programme, the ultra-compact SERV RISC-V core and its associated CoreScore benchmark, and work on FuseSoC and the spun-off Edalize.

“In closing, 2020 was a busy year FOSSi-wise,” Olof concludes. “And this has just touched upon the surface of all things that have been happening during the year.”

The full retrospective is available on Olof’s blog, Tales from Beyond the Register Map.

FuseSoC 1.12 Brings Cleaner Code, Better Testing, Rewritten Documentation

FuseSoC, the award-winning package manager and build toolchain for hardware description language (HDL) work, is now at version 1.12 — and the new release brings a range of improvements, not least of which can be seen in its rewritten documentation.

“We have good reasons to celebrate the 1.12 release of FuseSoC,” project creator and maintainer Olof Kindgren explains. “One of the most prevalent problems has been fixed, that of unreadable or non-existent documentation. Philipp [Wagner] 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.

“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.”

As well as the improved documentation the new release brings a code clean-up with deprecation warnings for functionality to be removed in FuseSoC 2.0, better and broader testing, and a new feature in the form of the ability to set parameters for generators directly in the targets.

Olof’s full write-up of the changes can be found on his blog, while the latest version of FuseSoC is available on GitHub under the permissive BSD 2-Clause licence.

Standard Semiconductor Releases Lion RISC-V Core for the VELDT Board

Standard Semiconductor has officially launched the Lion core, a RISC-V implementation with a difference: it’s written in Haskell using the Clash hardware description language, and targets the company’s Lattice Semiconductor iCE40-based VELDT FPGA board.

“Lion [is] a formally verified, 5-stage pipeline RISC-V core,” the company writes of the project. “Lion is written using Clash and available on Hackage as a library so that users may create their own System-on-Chip (SoC) around the Lion core.

“Currently the core implements the RV32I (without FENCE, ECALL, EBREAK) instruction set. Moving forward this will be the base default configuration, with all future features and extensions being integrated in a configurable manner.

“Future features include (but not limited to) Control and Status Registers and instructions (CSRs), a hard IP ALU, the ‘M’ architecture extension, and proper Dhrystone benchmarks,” the company promises. “Development will happen quickly, so check back periodically to see new features.”

The Lion core, along with tools used for formal verification, a system-on-chip implementation targeting the VELDT board, and a tool for observing Yosys synthesis metrics on the core, is available on Standard Semiconductor’s GitHub repository under the permissive BSD 3-Clause licence.

Xilinx Opens its Vitis HLS Front-End Source

FPGA specialist Xilinx has announced that its Vitis HLS high-level synthesis front end is now available under the Apache Licence 2.0, a move it hopes will encourage the extension, optimisation, and customisation of the HLS compilation pipeline.

“The Vitis HLS tool allows C, C++, and OpenCL functions to be deployed onto the device logic fabric and RAM/DSP blocks,” Xilinx’ Uttara Kumar explains. “Making the Vitis HLS front-end available on GitHub opens a new world of possibilities for researchers, developers and compiler enthusiasts to tap into the Vitis HLS technology and modify it for the specific needs of their applications.

“We’ve consistently enhanced our HLS technology for over 10 years to deliver increased design productivity for hardware developers and make the power of Xilinx adaptable platforms more broadly accessible to software and application developers without hardware design experience.”

As well as releasing the source code under a permissive licence, the release brings with it an injection use model which allows for third-party code transformations. The company has also boasted of a number of industry partnerships on the project, with engineers and researchers from Silexica, the University of Illinois at Urbana-Champaign, Imperial College London, and the Hong Kong University of Science and Technology (HKUST) all receiving early access.

The source code, with examples, is available on the Xilinx GitHub repository now.

QuickLogic Opens Crowdfunding for Ultra-Tiny Qomu eFPGA Development Kit

QuickLogic has opened a crowdfunding campaign for Qomu, an ultra-compact development board which combines a microcontroller and an embedded FPGA (eFPGA) — and boasts of a fully-open, vendor-supported toolchain.

“Meet Qomu, the latest in the *omu family of devices that fit inside your USB port,” the company writes of the design, which was created in partnership with Sean ‘xobs’ Cross and Sutajio Kosagi. “What’s different about Qomu? It’s not just an MCU, it’s not just an FPGA — it’s a complete SoC that fits inside a USB port.

“Qomu is differentiated by its vendor-supported open source tooling — even the FPGA tools. The Qomu dev kit is the most capable tiny USB device, featuring QuickLogic’s EOS S3 multicore MCU + eFPGA SoC and its suite of 100% open source tools, including Zephyr, FreeRTOS, nMigen, SymbiFlow, and Renode.”

The design uses QuickLogic’s EOS S3 SoC with an 80MHz Arm Cortex-M4F microcontroller, 512kB of RAM, an embedded FPGA with 2,400 effective logic cells and 64kB of embedded RAM with up to eight RAM/FIFO controllers, two dedicated multipliers for offload, 16-channel direct memory access (DMA), configurable SPI and I2C interfaces, 16Mb of flash, four capacitive touch pads, and a user-addressable RGB LED.

As well as using an open-source toolchain, the board design itself is open hardware with KiCad design files and Gerbers available on the project’s GitHub repository under the Creative Commons Attribution-ShareAlike 4.0 licence.

The Qomu crowdfunding campaign is open on Crowd Supply now, with rewards priced at $40 per board.

Enjoy Digital Gets LiteX, LiteDRAM, LiteEth, and Video Running on an Oscilloscope

FPGA specialist Enjoy Digital has got a Linux-capable free and open-source RISC-V core, plus supporting devices, up and running on an unusual target: A Siglent SDS1104X-E digital storage oscilloscope.

“Why have a FPGA dev board, a RISC-V dev board and a scope on your desk,” the company asks, “when your Zynq based Scope can do all? LiteX, LiteDRAM, LiteEth + the new Video Terminal core on a [Siglent] SDS1104X-E.”

The project gives the oscilloscope the surprising ability to boot into Linux, running on the LiteX RV32IMA core, and complete with access to networking via the scope’s own 10/100 Ethernet port. The video core, meanwhile, brings up the terminal on the scope’s own LCD front panel.

The source code for the project is split across various repositories on the Enjoy Digital GitHub with a video demo available on Twitter; so far the company has not released details on how to modify your own oscilloscope to achieve the same feat.

Ultra-Compact SERV RISC-V Core Hits the Microchip PolarFire FPGA

Engineer and RISC-V Ambassador Carlos Eduardo has succeeded in porting the ultra-compact SERV RISC-V core to the Microchip PolarFire FPGA.

“Lots of progress on Microchip Libero support for FuseSoC Edalize,” Carlos writes of his work in getting the PolarFire FPGA supported in open-source tools. “Thanks [to] Olof Kindgren for helping me polish it and others for tips. We’re getting close.”

The status update was quickly followed by a celebration of success: five SERV cores running on the PolarFire FPGA and taking up just 0.8 percent of its capacity. Bumping the number of cores up, though, may take a little longer: while 200 cores took up just 20 percent of the FPGA, the chip ran out of room in the sNVM — with Carlos suggesting that the fabric RAM could be used instead to support a many-core implementation. Some tweaks later, the PolarFire FPGA played host to an impressive 882 SERV cores.

“Great work by Carlos,” says SERV creator and FOSSi Foundation director Olof Kindgren, “and always a special kind of joy to see the SERV RISC-V core running on a completely new target.”

More information, and a discussion on supporting more cores and the core-counting Python script, can be found on Carlos’ Twitter; the SERV core itself is available on GitHub under the permissive ISC licence.

Marcus Geelnard Ports id Software’s Quake to His MRISC32-Based MC1 Computer

Developer Marcus Geelnard has shown off the capabilities of his 32-bit RISC/vector instruction set architecture (ISA) MRISC32 with a port of id Software’s classic first-person shooter Quake.

“Managed to compile Quake for MRISC32 after some GCC/MRISC32 stack frame fixes (Quake uses stack allocations a lot),” Marcus writes of his work. “Running in the simulator. Needs optimisations. Don’t know what to expect on FPGA/MRISC32-A1, but should probably be better.

“MC1-Quake is based on the original Quake v1.09 code base from 1997, with some bugfixes and alterations to make it work on MRISC32, and of course graphics and I/O routines for the MC1 computer.”

The port runs on the MC1, an FPGA-targeting compact computer based on the MRISC32-A1 soft microprocessor which in turn implements Marcus’ MRISC32 ISA — which, he explains in the project’s documentation, “tries to combine the good parts” of architectures including Cray-1, MIPS, and RISC-V “without repeating some unfortunate design decisions.”

A video demo of Quake running in the MRISC32 simulator is available on Vimeo, while the source code has been released on GitHub under the GNU General Public Licence 2. More information on MC1, MRISC32-A1, and MRISC32, including links to source code, can be found on the project’s dedicated website.

RISC-V International Announces Fast Track Architecture Extension Process

RISC-V International has announced a new streamlined ratification process for small extensions to the eponymous free and open source instruction set architecture — along with the first extension to use it, ZiHintPause.

“The Fast Track system enables us to more quickly address the needs of the RISC-V community as the diversity of RISC-V solutions and applications continues to grow exponentially,” claims Mark Himelstein, chief technology officer at RISC-V International. “The ratification of ZiHintPause demonstrates how this simplified process significantly accelerates the review of important extensions, while still maintaining RISC-V’s core tenant of openness with a public review period.”

The Fast Track process is applicable to architecture extensions meeting specific criteria, with RISC-V International promising “reasonable quality control” under the oversight of the relevant RISC-V standing committee. Extensions suitable for the process should be “simple, uncontentious, offer value to a large portion of the RISC-V community, and cleanly fit into existing RISC-V architecture,” the organisation explains.

ZiHintPause, which is designed to improve the performance of spin-wait loops and enable multithreaded cores to temporarily relinquish extension resources through the addition of a PAUSE instruction, is the first extension approved under the new process.

“We architected the ZiHintPause extension to improve the energy efficiency of synchronisation code in system software,” explains Andrew Waterman, Privileged Architecture Task Group Chair at RISC-V International and chief engineer at SiFive. “It’s a cost-effective and versatile extension that’s also well suited to a variety of other use cases where low-power operation is important.”

More information on the Fast Track Architecture Extension Process is available in this Google Docs file.

Sylvain Lefebvre Takes You on a Tour of a Yosys DSP Bug-Hunt

Silice creator Sylvain Lefebvre has hunted down a bug with using a Lattice Semiconductor iCE40 FPGA’s digital signal processor (DSP) via Yosys, and has published the process on Twitter for anyone interested in joining him in helping to improve open-source FPGA tooling.

“I tracked down a Yosys iCE40 DSP issue,” Sylvain begins as an introduction to his Twitter thread, “took a deep dive into Yosys internals and (I think?) squashed a tiny bug!

“It all started with this difference,” Sylvain continues, showing a video in which a texture is smoothly rotated around its centre with no DSP but spins off-centre when the DSP is enabled. “As I was only enabling the DSP cells (‘synth_ice40 -dsp’), this had to be the source of the issue, somehow.”

The thread then walks through how Sylvain was able to track down the apparent source of the problem — though with the warning that “I barely understand what’s going on, but thought sharing the process would be fun and interesting” — and culminates in a patch which appears to fix the problem.

“I’ll try to make a proper PR [pull request] out of this (if not already fixed!),” Sylvain concludes, “but due to my lack of understanding I am unsure I am truly fixing things, or making the problem worse somewhere else.”

The full thread is available on Sylvain’s Twitter, complete with before-and-after videos.