El Correo Libre Issue 44

Published in

LibreCores

15 min readNov 9, 2021

Cocotb 1.6.0 Provides Better HDL Datatypes, Improved Coroutine Scheduling, and More

The cocotb project — the COroutine based COsimulation TestBench — has announced the release of v1.6.0, which adds a range of improvements to the popular Python-based VHDL/Verilog RTL verification platform.

“This release concludes a seven month development period,” says Philipp Wagner of the project’s development progress. “Instead of going directly to cocotb 2.0, we threw in another backwards-compatible release in the 1.x release series with a number of exciting new features, and deprecations for functionality we will change in cocotb 2.0.

“All users of cocotb are strongly encouraged to look through the deprecations when running their tests and future-proof their testbenches as time permits!”

The new update brings with it a new method for scheduling coroutines, designed to replace the cocotb.fork() method of scheduling — which will remain available in v1.x but is now officially deprecated.

Another change comes in the introduction of datatypes which model common HDL data types — starting with Logic, Bit, Array, and LogicArray, all designed to be familiar to VHDL and SystemVerilog programmers and to provide type safety and useful typecasts.

More information on the features of the new release are available on the FOSSi Foundation blog, while the latest version is always available on the cocotb GitHub repository under the permissive Revised BSD Licence.

How Can We Fit All Our Clothes into a Small Suitcase? Overlay!

Did you ever think how wonderful it can be if your device will not be limit your program size? A device that can contain any oversize program.

We have MMU and OS that can do paging, but what if we have a small embedded device, an IoT controller that does not have room for HW MMU or a fat OS kernel.

Well, there is a solution, a software solution that does not involve any use of HW component.

In the early days of embedded computing, there was a technique to load code in Real-Time when it was needed for execution. This technique was named Overlay, and it was threaded with the toolchain (compiler, linker, and more), providing an accessible application interface for the SW developers.

NASA used this technique in their early shuttles flight control system. Flight computers had very limited memory, so they used SW overlays — only a small amount of code necessary for a particular phase of the flight (e.g., ascent, on-orbit, or entry activates) is loaded in computer memory at any one time.

At quiescent points in the mission, the memory contents are “swapped out” for program applications that are needed for the next phase of the mission. Read more at Statistical Software Engineering (1996) — Chapter: Case Study: NASA Space Shuttle Flight Control Software.

This technique slowly disappeared because memories became bigger, cheaper, and MMU emerged, replacing the need for paging software solutions.

Today, IoT devices (Internet of Things) are very strict with memory size and power, alongside requirements for simple HW implementation which does not contain MMU or a high-end operation system to manage it (Linux/Windows).

This technique gives the flexibility in reducing physical memory, and therefore reduces energy and space. It saves memory in magnitude proportions over any solution in the ISA domain (E.g., on RISCV: eABI, code-density, bitmanip, etc…)

So, how does it work?

A run-time module operates on the fast memory, deciding which function to load from a storage device to a fast memory heap. Code is dynamically loaded to “cache” and executed according to the program flow. The run-time module manages the cache and invoking the overlay functions.

The software engineer experience is very smooth; they need to add an _attribute_ to the function designated to be an overlay function, a function to load and execute only when called, and that is it.

For example:

void __attribute__ ((overlaycall)) bar(void);void foo(void)
{
        bar();
}

In contrast to MMU, Software Overlay is not using direct mapping; it means we can almost fit any program size to a very small heap/cache area. For example, 16Kbyte of cache can fit megabytes of code.

FOSSi Foundation and Overlay:
Western Digital took the Overlay task on itself; to standardise and develop an Overlay application for RISC-V to provide a solution for code size limitations in the RISC-V targets. The RISC-V organisation noticed that Overlay could be a good solution for any target and advised open-source for everyone.

At that time, a task group was created in the RISC-V org named overlay-tg; the goal is to provide a full application suite for Overlay, from the toolchain to a driving SW engine. Alongside, the Task-group created an official overlay standard that fits any target. It means a unified specification for Enginee and Toolchain applications that can be used for any target.

Lately, this standard was ported to FOSSi Foundation. The first step on porting all the Overlay suite to FOSSi Foundation.

Searching for Overlay applications on the web will quickly show no results. Especially not in open source and not for RISC-V. Supporting this feature on RISC-V and other targets will significantly improve the likelihood of the adoption of Overlay in smaller IoT.

-Ofer Shinaar, Lead, Software Overlay Committee

The original PDF version of this article is available on the FOSSi Foundation GitHub repository.

Enjoy Digital Boots Up a “100% Open Source” RISC-V FPGA Dev Board

Enjoy Digital has posted footage of a completely open-source FPGA development board built with RISC-V in mind booting up, offering impressive specifications and powered by repurposed Bitcoin mining hardware: the LiteX-Acorn-Baseboard.

“The board is mainly intended to be used as a development board for LiteX — from regression testing to development of new features,” the company explains of the project, “but can also be a nice and cheap FPGA development board for developers willing to play with PCIe, SFP, SATA, etc… or wanting to create stand-alone and open-source Linux platforms.

“The development has been specified and funded by Enjoy-Digital; also doing the HDL/Gateware development. The schematic/pcb has been designed by Ilia Sergachev who also assembled the initial prototypes.”

At the heart of the board is a SQRL Acorn, an FPGA board originally built to accelerate Bitcoin mining and since made obsolete by growing difficulty and more powerful alternatives. To this, the base-board adds a PCI Express 1.0 connector, SFP, M.2 SATA, an additional EPC5 FPGA connected via SERDES, gigabit Ethernet, HDMI, SD card, an LCD, two SATA ports, four PMOD ports, two buttons, and a JTAG/UART port.

The video of the board, configured with 1GB of DDR3 memory and an M.2 SATA SSD for storage, is available on Twitter; more details and schematics are available on the project’s GitHub repository with design files and Gerbers to follow once the board has been validated.

Matthew Venn Highlights Lessons Learned as Faulty MPW1 Silicon Lands

The silicon built as part of the MPW1 shuttle, a SkyWater production run organised by efabless and funded by Google, has landed — and revealed some mistakes which prevent it from being used to its full potential, as explained by Zero to ASIC course creator Matthew Venn.

Efabless’ Open MPW programme allowed free and open source silicon projects to submit designs for physical production — with all costs associated with having the silicon fabbed by SkyWater covered by Google. It was, and remains, an amazing project which attracted a wealth of designs for the initial production run, but the first silicon back revealed some issues.

“It’s possible to load some firmware and flash an LED,” Matthew explains, “but unfortunately it’s not possible to control the GPIOs. The GPIO that is flashing at the moment is this one that’s inside the management area, but we can’t set up the GPIO pins to turn them into inputs or outputs — and that means any projects that depend on them working are not going to work.

The problem lies in a timing issue, whereby clocks are arriving at a time which causes a hold violation — something which cannot be resolved by tweaking clock speeds, but is impacted by operating voltage and temperature. “You might be asking why we didn’t catch this problem before we taped out for MPW1,” Matthew says, “and that’s a really good question, and the answer is that we thought it was.

“There’s at least two [problems]: one is that we didn’t have the full parasitics of the clock network because we were missing some information, and that information is now being provided by a tool called OpenRCX, and the second thing is it looks like there was a misconfiguration with how OpenSTA was actually being run so it wasn’t paying attention to clock propagation. When we add both those things and then re-run the checks we can see that the clock network for caravel has a 10 nanosecond skew — and that causes all the hold violations that have been causing these problems.”

Now the problem is understood, things are looking brighter for future production runs. Matthew’s full explanation, meanwhile, is available on the Zero to ASIC Course YouTube channel.

The GNU Compiler Collection (GCC) Adds “Minimal Support” for RISC-V Bitmanip

The GNU Compiler Collection (GCC) project has merged initial support for using the RISC-V Bitmanip (Bit Manipulation) instruction set extensions, as reported by Phoronix, with stable support expected to land in GCC 12.1 next year.

The code, submitted to the project by SiFive’s Kito Cheng and merged in late October, adds what is described as “minimal support” for the extensions, which were originally proposed in 2017 as XBitmanip before being renamed to RISC-V Bitmanip back in 2019.

In the words of the Bitmanip Task Group, the extensions are designed to “enable the development of code that is substantially more performant and efficient that what is possible with the base [RISC-V] instructions,” and include extensions designed to boost performance and lower power and memory requirements.

The minimal implementation adds instruction patterns and cost models for the ZBA, ZBB, and ZBS extensions, but not ZBC, ZBKB, ZBKC, or ZBKX.

The support is expected to land in the stable release of 12.1 some time early next year.

Alibaba’s T-Head Releases Four Free and Open-Source RISC-V Cores

T-Head, the semiconductor arm of Alibaba, has released four RISC-V processor cores under permissive licences: The XuanTie E902, E906, C906, and C910.

Previously announced as proprietary cores, the C906 and C910 are Linux-capable RISC-V cores designed with the Internet of Things (IoT) in mind. The former is a low-power in-order core which was first commercialised in Allwinner’s D1 system-on-chip as a single core running at 1GHz; the latter is a higher-performance out-of-order design which is to land on an early development board as a two-core cluster.

These two more complex cores are joined by a pair of simpler cores, built for devices with more tightly constrained resources: The E902 and the E906. In all four cases, the designs are made available under the permissive Apache 2.0 licence.

“By opening up the IP cores of our in-house IoT processors as well as related software stacks and development tools, we aim to assist global developers to build their own RISC-V-based chips in a much more cost-effective way,” Jeff Zhang, president of Alibaba Cloud and head of the Alibaba DAMO Academy, says of the release. “We hope this move can encourage more innovation among the thriving RISC-V software community, and as a result help people to enjoy the benefits of a connected world in the digital era.”

Following the release, FOSSi Foundation director and FuseSoC creator Olof Kindgren began the process of adding support for the performance-centric C910 core — and invited others to learn how it’s done by live-Tweeting the experience.

All four cores, known as the OpenE902, OpenE906, OpenC906, and OpenC910 respectively, are available now on the T-Head GitHub repository, with additional resources — including documentation and an official software development kit — to follow.

CHIPS Alliance Recaps its Fall 2021 Workshop, Boasts of Nearly 160 Attendees

CHIPS Alliance recently held its autumn workshop, with 160 attendees there to see eight key technical presentations covering topics from the porting of the Android Open Source Project (AOSP) to RISC-V to automated open-source analogue and mixed-signal integrated circuit generation.

The eight presentations held during the event were:

Porting Android to RISC-V — Guoyin Chen and Han Mao, Alibaba
Practical Adoption of Open Source SystemVerilog Tools — Michael Gielda, Antmicro
Chisel and FIRRTL for Next-Generation SoC Designs — Jack Koenig, SiFive
OpenFASOC: Automated Open Source Analog and Mixed-Signals IC Generation — Mehdi Saligane, University of Michigan (UMICH)
FPGA Tooling Interoperability with the FPGA Interchange Format — Maciej Kurc, Antmicro
OmniXtend: Scalability and LPC — Jaco Hofmann, Western Digital Corporation
Open Source NVME IP with AI Acceleration — Anand Kulkarni, Western Digital Corporation and Karol Gugala, Antmicro
Automating Analog Layout using ALIGN — Sachin Sapatnekar, University of Minnesota (UMN)

“Each of these talks provided informative, technical details of key aspects of the work underway by members of CHIPS Alliance who are working in an open, collaborative fashion,” the organisation wrote in its event recap.

All presentations made during the event are available to watch now on the CHIPS Alliance YouTube channel, with slides available on the website alongside information on upcoming events.

OpenBSD Gets Support for 64-bit RISC-V in its Latest 7.0 Release

Free and open source operating system OpenBSD has now received support for the 64-bit version of the free and open source RISC-V instruction set architecture, as reported by CNX Software — though, initially, it’s only fully supported on the HiFive SiFive Unmatched development board.

As of OpenBSD 7.0, it’s possible to boot the operating system on the HiFive Unmatched’s RISC-V processor cores. “When booting the HiFive Unmatched board, write an install/miniroot image to a USB flash drive, and boot with that drive plugged in,” the port’s notes explain.

“Make sure you also have the microSD card plugged in that shipped with the HiFive Unmatched board. The board should auto-boot the OpenBSD bootloader, which will load the bsd.rd RAMDISK install kernel.”

OpenBSD 7.0 also includes partial support for booting on the Microsemi PolarFire SoC Icicle FPGA development board, which ships with a RISC-V SoC — but, the port’s maintainers warn, “support is incomplete” for this target.

More details on the port are available on the OpenBSD website, along with more general release notes for OpenBSD 7.0 itself.

Jürgen Müller’s 100MHz 6502 is a Drop-In Performance Booster for Vintage Computers

Jürgen Müller has built a clone of the classic MOS Technology 6502 processor with a difference: it’s an FPGA-based pin-compatible drop-in replacement running at up to 100MHz.

“The 6502 was the CPU in my first computer (an Apple II Plus), as well as many other popular home computers of the late 1970s and 80s,” Jürgen explains. “It lived on well into the 1990s in game consoles and chess computers, mostly in its updated ‘65C02’ CMOS version. Here’s a re-implementation of the 65C02 in an FPGA, in a pin-compatible format that lets you upgrade those old computers and games to 100 MHz clock rate!

“I packaged this in a Spartan-6 FPGA (with 64 kByte on-chip RAM), on a small circuit board which is just the size of a 40-pin dual inline package, with pins matching the 65C02 pinout. I added logic inside the FPGA which can access the external 65C02 bus with the correct timing, based on whatever clock is coming in from the host system. Inside the FPGA, the CPU core runs at 100 MHz. I dubbed this the ‘65F02’, where the ‘F’ might stand for FPGA or for ‘Fast’.”

The project builds on a 6502 core originally developed by Arlet Ottens and extended by Ed Spittles and David Banks, with Jürgen adding the DIP-form-factor Spartan-6 FPGA board.

More details, along with Gerber files, schematics, and board layout files, are available on Jürgen’s blog under an unspecified licence.

Antmicro Details OpenLane Build Flow Improvements, SystemVerilog Support

Antmicro has written of its work to improve the OpenLane ASIC build flow through the addition of open-source SystemVerilog support, which it says is key in “making the flow more useful for practical designs.”

“One of CHIPS Alliance’s projects, the DARPA-funded OpenROAD, has created the necessary tooling to build open source ASIC-oriented flows such as OpenLane and OpenFASoC, becoming one of the central elements of the open ASIC ecosystem,” the company explains.

“The hope for open source ASIC flows like OpenLane is to provide multiple benefits: enable new, less conventional approaches; provide more capabilities of vertical integration; encourage more software-driven and AI-assisted workflows; use the infinite scalability of the cloud without worrying about licensing costs.

“Our latest improvement in the OpenLane open source ASIC build flow,” the company continues, “is adding a Surelog/UHDM/Yosys flow that enables SystemVerilog synthesis without the necessity of converting the HDL code to Verilog as an intermediate step.”

The addition allows, Antmicro explains, for OpenLane to work with a number of existing SystemVerilog-based ASIC designs — including OpenTitan’s Ibex core and Earl Grey SoC, OHG’s Core-V, the University of Washington’s BlackParrot, and Western Digital’s SWeRV.

More details, including instructions on getting started with SystemVerilog support in OpenLane, are available on the Antmicro blog.

Low Level JavaScript Builds the World’s First TypeScript RISC-V CPU

Francis Stokes, creator of the Low Level JavaScript YouTube channel, has been building a RISC-V CPU with a difference: it’s implemented in TypeScript, Microsoft’s version of JavaScript with static typing.

“If you’ve never seen any of my videos before,” Francis jokes, “then that probably sounds completely insane. Gateware-ts is this library that I’ve written which is a hardware definition library — kind of like a hardware definition language — that’s embedded in the TypeScript programming language.

“What that means is you can specify hardware in TypeScript and then you can take that description and turn it into something that can run on an FPGA — or, actually, if you wanted to, something that could become a silicon chip.

“It works great for this channel,” Francis continues, “because this channel is Low Level JavaScript and it’s kind of like, you know, let’s make the weirdest and the most like obscenely low-level stuff in a language that really doesn’t seem like it should be used for that — and that’s kind of the fun of it.”

The first video in the series is available on the Low Level JavaScript channel now, while gateware-ts has been published to GitHub under an unspecified licence.