Skip to main content
Category

Blog

Open Source Debayerization Blocks in FPGA

By Blog

This post was originally published at Antmicro.

In modern digital camera systems, the captured image undergoes a complex process involving various image signal processing (ISP) techniques to reproduce the observed scene as accurately as possible while preserving bandwidth. On the most basic level, most CCD and CMOS image sensors use the Bayer pattern filter, where 50% of the pixels are green, 25% are red and 25% are blue (corresponding to the increased sensitivity of the human eye to the green color). Demosaicing, also known as debayering, is an important part of any ISP pipeline whereby an algorithm reconstructs the missing RGB components/channels of each pixel by performing interpolation of the values collected for individual pixels.

Diagram depicting debayerization process

The rapid development of FPGA technologies has made it possible to use advanced ISP algorithms in FPGAs even for high-res, multi-camera arrays, which is great news for resource-constrained real-time applications where image quality is essential. In our R&D work, we are developing reusable open source building blocks for various I/O and data processing purposes that can be used as a starting point for customer projects which need to be bootstrapped quickly, and those include IP cores for debayerization.

Open source debayerization

As part of a recent project, we implemented and tested an open source FPGA-based demosaicing system that converts raw data obtained from CCD or CMOS sensors and reconstructs the image using three different interpolation algorithms controlled via a dedicated wrapper. The three interpolation methods are:

  • Nearest neighbour interpolation, where the nearest pixel is used to approximate the color value. This algorithm is simple to implement and is common in real-time 3D rendering. It uses a 2×2 px matrix and is the lightest and easiest method to implement.
  • Bilinear interpolation, which establishes color intensity by calculating the average value of the 4 nearest pixels located diagonally in relation to the given pixel. This method uses a 3×3 px matrix and gives better results than the nearest neighbour interpolation method but takes up more FPGA resources.
  • Edge directed interpolation, which calculates the pixel components in a similar way to bilinear interpolation, but uses edge detection with a 5×5 px matrix. This algorithm is the most sophisticated of the three, but gives the best results and eliminates zippering.

System structure

The demosaicing system consists of two parts. The most important part is formed by the demosaicing cores representing the three algorithms described earlier.

Diagram depicting dmosaicing wrapper

The software part of the system runs in the FPGA and features the bootloader, operating system (Linux), Antmicro’s open source FastVDMA IP core that controls data transmission between the demosaicing setup and the DDR3 memory, and a dedicated Linux driver that makes it possible to control the demosaicing cores from software.

Open source FPGA IP cores for vendor-neutral solutions

Apart from building highly-capable vision systems based on FPGA platforms, we are developing various tools, open source IP cores and other resources to provide our customers with a complete, end-to-end workflow that they can fully control.

Some of our recent projects include the FPGA Interchange Format to enable interoperability between FPGA development tools, an open source PCIe link for ASIC prototyping in FPGA or an FPGA-based testing framework for hardware security of DRAM. If you would like to benefit from introducing a more software-driven, open source friendly work methodology into your next product development cycle, reach out to us at contact@antmicro.com and keep track of our growing list of open IP cores at the Antmicro Open Source Portal.

How Google is Applying Machine Learning to Macro Placement 

By Blog

CHIPS Alliance’s latest Deep Dive Cafe featured an outstanding talk by a Google physical design engineer, Young-Joon Lee, who has a PhD from Georgia Tech, and has been working on machine learning physical design projects for the past two years. 

The chip placement problem is a notoriously challenging design problem, and has been explored in the electronic design automation research and development community for years. For those unfamiliar with the problem, it involves finding the optimal placement of physical cells implementing the logical function on a chip image to minimize performance, power, and area of the silicon, which in the end affects the cost of the product. The effort by Google to apply machine learning to the placement problem started as part of the Google Brain effort, which in part focuses on running algorithms at scale on large amounts of data.

Deep learning itself started taking off in 2012, with computational needs rapidly increasing every three to four  months. Machine learning is particularly applicable to the placement problem as different moves that are tried for training can be fed back to the underlying network as part of reinforcement learning. Models are trained and scale on distributed systems with billions of parameters. 

In this talk, Young-Joon shared how Google devised a hybrid approach to the placement problem, first placing large macros with reinforcement learning, and then using force directed placement for standard cells. As part of this effort, Google used an open source RISC-V processor called Ariane. The presentation highlighted the quality of results achieved, challenges, and the overall designer productivity that was afforded with the development of this technique. Of note, the recently released TPU v4 was able to be placed within 24 hours by the machine learning approach compared to six to eight  weeks by a physical design engineer, achieving 3% shorter wirelengths and 23 more DRC violations. 

Finally, next steps in the project were discussed as well as how Google is exploring more machine learning techniques to use for other parts of electronic design automation. 

Watch the presentation below and check out the slides here: Learning To Play the Game of Macro Placement with Deep Reinforcement Learning.

Improving the OpenLane ASIC Build Flow with Open Source SystemVerilog Support

By Blog

This post was originally published at Antmicro.

Open source toolchains are key to building collaborative ecosystems, welcoming to new approaches, opportunistic/focused innovations and niche use cases. The ASIC design domain, especially in the view of the rising tensions around manufacturing and supply chains, are in dire need of a software-driven innovation based on an open source approach. The fledgling open source hardware ecosystem has been energized by the success of RISC-V and is now being vastly expanded to cover the entire ASIC design flow by CHIPS Alliance, and Antmicro has been playing a leadership role in both of these organizations as well as offering commercial engineering and support services to assist with early adoption of open source approaches in hardware.

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 OpenROAD project, led by prof. Andrew Kahng from University of California San Diego, aims at a fully end-to-end, RTL-GDSII flow, providing accessibility and collaboration options that are often not available for proprietary tools.

Antmicro is helping early adopters of OpenROAD-based flows, providing development services improving the tools themselves – such as the open source SystemVerilog support described in this note. Our engineering services involve introducing better, open workflows on the design and implementation level, but also scaling up into the cloud in collaboration with Google Cloud.

There has been a lot of progress recently in the practical adoption of open ASIC design workflows, with most of the effort currently focused around the fully open source 130 nm SkyWater PDK for the release of which we collaborated with Google, efabless, SkyWater Technologies and many others. What is perhaps less known is that there have been successful tapeouts based on OpenROAD in more modern processes such as GF12 (and together with our customers we are planning more next year), but of course there is a long way to go until the toolchain can be considered a viable replacement for your latest-gen smartphone SoC design. There are, however, serious advantages in favor of an open source ASIC design flow, and to get there, delivering practical value in useful increments is needed. This is why we are working in CHIPS Alliance on making the flow more useful for practical designs.

Why open source tools for ASIC development?

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

In this early and emerging ecosystem, having a commercial support partner like Antmicro which can be relied on for the tools development is important for success – this lets you focus on your design while we take care of the infrastructure needs. Already now there are many niche use cases which can benefit from employing point open source improvements, and our work in CHIPS aims at broadening the application area of open source ASIC design flows to capture the needs of the broader market and bring the benefits of software innovation to hardware. We offer flexible, scalable engineering services to support our customers every step of the way.

Open Source SystemVerilog support in OpenLane

OpenLane is an automated RTL to GDSII flow that is composed of several tools such as OpenROADYosysMagicNetgenFaultCVCSPEF-ExtractorCU-GRKlayout and a number of scripts used for design exploration and optimization. This collection of tools performs all steps required in a full ASIC implementation from RTL to GDSII.

The flow, depicted below, consists of several highly customizable stages. In the initial stage the RTL source files written in an HDL (Hardware Description Language) are synthesized, technology mapped and analyzed in terms of timing. In the following step the floorplan and power distribution network are prepared for the design placement. Once finished, the design and clock placement is performed followed by global routing. With the physical layout ready in the form of a DEF (Design Exchange Format) file, it’s possible to perform several DRC checks, including Antenna Net or LVS (Layout vs. Schematic), to eventually generate the final GDSII layout file which contains a complete layout description that is now ready to be sent to the foundry.

Diagram depicting openlane flow

Our latest improvement in the OpenLane open source ASIC build flow 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.

Yosys is a highly extensible open source HDL synthesis tool used in the RTL synthesis step of the OpenLane flow. Yosys has extensive Verilog-2005 support, but it needs additional plugins to support other languages such as VHDL or SystemVerilog. Previously, SystemVerilog support was only supported with a proprietary plugin, but Antmicro has been involved in adding the SystemVerilog support to Yosys through recent contributions adding UHDM (Universal Hardware Data Model) frontend which has been described in a separate Blog note. UHDM is a file format for storing hardware designs and at the same time a library able to manipulate this format. Designs written in SystemVerilog can be elaborated to the UHDM format by Surelog, which is a tool that aims to be a fully-featured SystemVerilog 2017 preprocessor, parser and elaborator. In our recent efforts both the Surelog parser library and the UHDM library have been integrated with Yosys which essentially enabled seamless SystemVerilog support.

Diagram depicting surelog/uhmd -> yosys

This combination of Surelog/UHDM/Yosys is a very practical improvement for the OpenLane ASIC build flow as it enables using it with a number of existing ASIC designs which are often implemented with SystemVerilog (e.g. OpenTitan’s Ibex/Earl Grey (an SoC based on Ibex), OHG’s Core-VUniversity of Washington’s BlackParrotCHIPS Alliance’s SWeRV).

Together with Google, we are working with relevant communities to prove the feasibility of these designs with our open source flows and the open source SkyWater PDK.

Building and testing OpenLane with SystemVerilog support

The OpenLane toolchain relies on dockerized tools to implement the flow in practice. This allows the users to focus on building the designs without the necessity of handling complex tools dependencies.

In order to add SystemVerilog support to OpenLane, you need to have a Docker container with Yosys with UHDM support. First you will need to install the OpenLane flow files as well as the PDK (Process Design Kit) files.

git clone https://github.com/The-OpenROAD-Project/OpenLane.git
cd OpenLane

make openlane 
make pdk 
cd docker_build/
make build-yosys DOCKER_BUILD_OPTS=--no-cache
make merge

Once the tools are built and containers recreated, you can see the tools in action using this example CI run:

export IMAGE_NAME=<docker image name>
make test

Optionally, you can run the OpenLane container in interactive mode and manually run the OpenLane flow script.

export IMAGE_NAME=<docker image name>
make mount
./flow.tcl -design spm 
exit

The IMAGE_NAME environment variable selects which Docker image will be used. If not set, a default OpenLane image will be fetched from DockerHub. The default image does not implement the Surelog/UHDM/Yosys flow and will, most likely, fail when used with the synthesis scripts from the repository.

The Surelog/UHDM flow is very similar to the original (Verilog only) flow, but differs in the way Yosys handles the RTL design. This is because Surelog and UHDM (along with the Yosys UHDM frontend) are packed into a library and loaded into Yosys as a plugin. Loading the plugin is one of the first steps of the synthesis process. Once the plugin is loaded, you can proceed to loading the RTL files and continue with the rest of the flow.

Early adoption services for open source in ASIC design

At Antmicro, we are providing services to our customers developing custom ASICs on many levels both IP, tools (Yosys, VPR, OpenROAD, Renode etc.) as well as cloud scaling (distant, custom GitHub runners etc.), focusing on interoperability between the many building blocks needed for a complete ASIC design flow.

Our collaboration with CHIPS Alliance partners like Google and Western Digital has been spawning many interesting projects which contributed to maturing the open source ecosystem. Our linting and formatting work, used by such projects like OpenTitan and Core-V, recently presented at the CHIPS Alliance Fall Workshop, is a very good example of delivering incremental value with solutions to practical problems. Other projects which enable the blending of old and new methodologies for chip design are the efforts towards UVM support in Verilator or co-simulation in Renode.

Recap of the Fall 2021 CHIPS Alliance Workshop

By Blog

We recently held our fall 2021 CHIPS Alliance workshop with nearly 160 attendees present for informative seminars covering a range of topics including porting Android to RISC-V, open source ASIC design and FPGA tooling, and OmniXtend. In case you missed the talks, a replay is available on the CHIPS Alliance YouTube channel.

During the seminar, we had eight exciting technical presentations, including:

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. Of particular interest are the following topic areas:

Porting Android to RISC-V

The presence of RISC-V is significantly growing, thanks in part to its applicability for the IoT, mobile market, and even the data center. Alibaba shared its experience porting the Android operating system to RISC-V, discussing their challenges and successes, and what is needed to help build out the ecosystem for the RISC-V ISA.

Design Languages: Practical Adoption of Open Source SystemVerilog Tools, and Chisel and FIRRTL for Next Generation SoC Designs

These two talks showcased the continuing efforts to build robust support for different design description languages. 

In the first talk, Antmicro provided an overview on the latest developments in open source SystemVerilog tooling, covering the construction of the ecosystem and efforts to support SystemVerilog more robustly, including the creation of a Universal Hardware Data Model (UHDM), continued support of two industry-grade SystemVerilog parsers – Surelog and Verible – as well as a set of tests and scoreboard to determine the quality of different SystemVerilog applications and work towards UVM support in Verilator.

From CI-assisted linting and formatting to fully open source synthesis and simulation, the talk pointed out that adding SV support to open ASIC design flows is a way to make emerging ecosystems such as OpenLANE/OpenROAD work with the growing number of designs described in this language (e.g. OpenTitan’s Ibex/Earl Grey, OHG’s Core-V, University of Washington’s BlackParrot, or CHIPS Alliance’s SWeRV). The future of open ASIC design, as spearheaded by members of CHIPS, will be pluralistic. 

The talk on Chisel and FIRRTL updated the community on the progress with the Chisel design language, which is based upon Scala. For those who are unfamiliar, this introduces object oriented design concepts and expression to a hardware design language. Similar to what occurred in software, the introduction of object oriented concepts serves to increase the productivity of a hardware design engineer. FIRRTL provides a hardware compiler for a design described in Chisel. A key feature of this is the ability to natively embed formal verification as part of the design, which is typically a difficult task. FIRRTL also enables target output to different applications including Verilator for functional verification, OpenROAD for physical implementation, and for FPGA emulation. 

FPGA Tooling Interoperability with the FPGA Interchange Format

Over the past few years, FPGAs have become a strategic component in the arsenal of different computational platforms, from labs and desktops to datacenters. Their flexibility to be dynamically reconfigured based upon updates to underlying changes in the hardware design and its emulation make them very helpful for rapid prototyping of new ideas and quickly moving into production. This has been a tremendous benefit for the rapid development and deployment of new machine learning algorithms and their usage in the datacenter. 

This talk discussed work to provide a common open device and design representation format, enabling various FPGA design toolchains (both open source and proprietary) to seamlessly interoperate in a design build task. With the Interchange format in place a designer can choose between tools available in different toolchains (e.g. place design with an open source flow, and later route it with a proprietary one).This will enable different companies, universities, and individuals to focus on research and development on a certain part of the flow, without the necessity of implementing the whole toolchain at once. 

OmniXtend Scalability and LPC

This session highlighted the progress of the joint working group with RISC-V International on the cache coherency project, which is making the protocol extensible to a family of participant devices. The talk started with a brief tutorial on the nature of OmniXtend. This update specifically highlighted the extension of OmniXtend to be able to dynamically detect the addition or subtraction of devices to the shared bus between intelligent devices. This 1.1 version of the protocol will be fully released under the Apache 2.0 license in Github.

Open Source NVME IP with AI Acceleration

This talk discussed the need for machine learning accelerators in proximity to data storage. The talk covered the overall architecture of a data-centric, parallel processing system developed by Antmicro in collaboration with Western Digital, including FPGA implementation of the NVMe core and software architecture with Zephyr RTOS running on the Cortex-R5 RPU and Linux on the Cortex-A53 core of the Xilinx UltraScale MPSoC chip. Both systems use OpenAMP for asynchronous communication, allowing the RTOS to handle base NVMe commands and delegate the rest to the Linux application. To speed up ML algorithm inference, VTA (an open source FPGA AI accelerator) was employed. The ML algorithms were developed using TensorFlow Lite. 

Analog design automation: OpenFASOC and ALIGN

Analog design is still considered magic to most of us. Unbeknownst to many, analog is a key part of many of the electronic devices we enjoy, not the least of which is the mighty smartphone. Analog design is typically the long pole in a chip design schedule, often performed by a select group of engineers and done primarily by manual means. Both of these talks discussed efforts to automate the analog design process, significantly improving the productivity of the design team, reducing the time to market, and also enabling technology migration from process node to node. 

Our next technical talk will be a CHIPS Deep Dive Cafe Talk on Tuesday, Nov. 9 at 8 a.m. PT entitled “Learning To Play the Game of Macro Placement with Deep Reinforcement” by Young-Joon Lee of Google. I hope you are able to join us for this exciting and informative talk. To register, please visit here.

Open Source DDR Controller Framework for Mitigating Rowhammer

By Blog

This post was originally published at Antmicro.

Rowhammer is a hardware vulnerability that affects DRAM memory chips and can be exploited to modify memory contents, potentially providing root access to the system. It occurs because Dynamic RAM consists of multiple memory cells packed tightly together and specific access patterns can cause unwanted effects that propagate to nearby memory cells and cause bit-flips in cells which have not been accessed by the attacker.

The problem has been known for several years, but as shown by most recent research from Google performed with the open source platform Antmicro developed that we’ll describe in this note, it has yet to be completely solved. The tendency in DRAM manufacturing is to make the chips denser to pack more memory in the same size which inevitably results in increased interdependency between memory cells, making Rowhammer an ongoing problem.

Rowhammer attack diagram

Solutions like TRR (Target Row Refresh) introduced in newer memory chips help mitigate the issue, although usually only in part – and new attack methods like Half-Double or TRRespass keep emerging. To go beyond the all-too-often used “security through obscurity” approach, Antmicro has been helping build open source platforms which give security researchers full control over the entire technology stack, and enables them to find new solutions to emerging threats.

The Rowhammer Tester platform

The Rowhammer Tester platform was developed for and with Google, who just like Antmicro believe that open source, well documented technical infrastructure is critical in speeding up research and increasing collaboration with the industry. In this case, we wanted to enable the memory security researchers as well manufacturers to have access to a flexible platform for experimenting with new types of attacks and finding better Rowhammer mitigation techniques.

Current Rowhammer test methods involve using the chip-specific MBIST (Memory Built-in Self-Test) or costly ATE (Automated Test Equipment), which means that the existing approaches are either costly, inflexible or both. MBIST are specialized IP cores that test memory chips for errors. Although effective, they lack flexibility in terms of changing testing algorithms hardcoded into the IP core. ATEs devices are usually used at foundries to run various tests on wafers. Access to these devices is quite limited and expensive therefore chip vendors have to rely on DFT (Design for Test) software to produce compressed test patterns which require less access time to ATE while ensuring high test coverage.

The main goal of the project was to address those limitations, providing an FPGA-based Rowhammer testing platform that enables full control over the commands sent to the DRAM chip. This is important because DRAM memory requires specialized hardware controllers and any software-based testing approaches have to communicate with the DRAM indirectly via the controller, which pulls the researchers away from the main research subject when studying the DRAM chip behaviour itself.

Platform architecture

Rowhammer test platform architecture diagram

The Rowhammer Tester consists of two parts: the FPGA gateware that is loaded to the hardware platform and a set of Python scripts used to communicate with the FPGA system from the user’s PC. Internally all the important modules of the FPGA system are connected to a shared WishBone bus. We use an EtherBone bridge to be able to interface with the FPGA WishBone bus from the host PC. EtherBone is a protocol that allows to perform regular WishBone transactions over Ethernet. This way we can perform all of the communication between the user PC and the FPGA efficiently through an Ethernet cable.

The FPGA gateware has 3 main parts: a Bulk transfer module, a Payload Executor and the LiteDRAM controller along with a VexRiscv CPU. The Bulk transfer module provides an efficient way of filling and testing the whole memory contents. It supports user-configurable access and data patterns, using high-performance DMA to make use of full bandwidth offered by the LiteDRAM controller. When using the Bulk transfer module, LiteDRAM handles all the required DRAM logic, including row activation, refreshing, etc. and ensuring that all DRAM timings are met.

In case when more fine-grained control is required, our Rowhammer Tester provides the Payload Executor module. Payload Executor can be thought of as a simple processor that can execute our custom instruction set. Most of the instructions map directly to DRAM commands, with minimal control flow provided by the LOOP instruction. A user can compile a “program” and load it to Rowhammer Tester’s instruction SRAM, which will be then executed. To execute a program, Payload Executor will disconnect the LiteDRAM controller and send the requested command sequences directly to the DRAM chip via the PHY’s DFI interface. After execution the LiteDRAM controller gets reconnected and the contents of the memory can be inspected to search for potential bit-flips.

In our platform we use LiteDRAM which is an open-source controller that we have been using in multiple different projects. It is part of the wider LiteX ecosystem, which is also a very popular choice for many of our FPGA projects. The controller supports different memory types (SDR, DDR, DDR2, DDR3, DDR4, …), as well as many FPGA platforms (Lattice ECP5, Xilinx Series 6, 7, UltraScale, UltraScale+, …). Because it is an open source FPGA IP core, we have complete control over its internals. That means two things: firstly, we were able to easily integrate it with the rest of our system and contribute back to improve LiteDRAM itself. Secondly and perhaps even more importantly, the controller can be modified by groups focused on researching new memory attacking methods in order to expose existing vulnerabilities. The results of such experiments should essentially motivate vendors to work on mitigating the uncovered flaws rather than rely on the “security by obscurity” based approach.

Our Rowhammer Tester is fully open source. We provide an extensive set of Python scripts for controlling the board, performing rowhammer attacks and harvesting the results. For more complex testing you can use the so-called Playbook, which is a framework that allows to describe complex testing scenarios using JSON files, providing some predefined attack configurations.

Antmicro is actively collaborating with Google and memory makers to help study the Rowhammer vulnerability, contributing to standardization efforts under the JEDEC initiative. The platform has already been used to a lot of success in state-of-the-art Rowhammer research (like the case of finding a new type of Rowhammer attack called Half-Double, as mentioned in the opening paragraph).

New DRAM PHYs

Initially our Rowhammer Tester targeted two easily available and price-optimized boards: Digilent Arty (DDR3, Xilinx Series7 FPGA) and Xilinx ZCU104 (DDR4, Xilinx UltraScale+ FPGA). They were a good starting point, as DDR3 and DDR4 PHYs for these boards were already supported by LiteDRAM. After the initial version of the Rowhammer Tester was ready and tested on these boards, proving the validity of the concept, the next step was to cover more memory types, some of which find their way into many devices that we interact with on a daily basis.

A natural target was the LPDDR4 DRAM – a relatively new type of memory designed for low-power operation with throughputs up to 3200 MT/s. For this end, we designed our dedicated LPDDR4 Test Board, which has already been covered in a previous blog note.

LPDDR4 test platform

The design is quite interesting because we decided to put the LPDDR4 memory chips on a module, which is against the usual practice of putting LPDDR4 directly on the PCB, as close as possible to the CPU/FPGA to minimize traces impedance. The reason was trivial – we needed the platform to be able to test many memory types interchangeably without having to desolder and resolder parts, using complicated interposers or other niche techniques – the platform is supposed to be open and approachable to all.

Alongside the hardware platform we had to develop a new LPDDR4 PHY IP as LiteDRAM didn’t have support for LPDDR4 at that time, resolving challenges related to the differences between LPDDR4 and previously supported DRAM types, such as new training modes. After a phase of verification and testing on our hardware, the newly implemented PHY has been contributed back to LiteDRAM.

What’s next?

The project does not stop there; we are already working on an LPDDR5 PHY for next-gen low power memory support. This latest low-power memory standard published by JEDEC poses some new and interesting challenges including a new clocking architecture and operation on an even lower voltage. As of today LPDDR5 chips are still hardly available on the market as a bleeding-edge technology, but we are continuing our work to prepare LPDDR5 support for our future hardware platform in simulation using custom and vendor provided simulation models.

The fact that our platform has already been successfully used to demonstrate new types of Rowhammer attacks proves that open source test platforms can make a difference, and we are happy to see a growing collaborative ecosystem around the project in a joint effort to ensure that we find robust and transparent mitigation techniques for all variants of Rowhammer for the foreseeable future.

Ultimately, our work with the Rowhammer Tester platform shows that by using open source, vendor-neutral IP, tools and hardware, we can create better platforms for more effective research and product development. In the future, building on the success of the FPGA version, our work as part of the CHIPS Alliance will most likely lead to demonstrating the LiteDRAM controller in ASIC form, unlocking even more performance based on the same robust platform.

Listen to CHIPS Alliance’s Rob Mains on EE Journal’s FishFry Podcast

By Blog

CHIPS Alliance’s general manager Rob Mains joined Amelia Dalton at EE Journal’s FishFry podcast for a lively discussion about how we’re working to make chip design more accessible. Rob discussed CHIPS Alliance’s work with RISC-V International to develop a new unified memory standard, along with our work to accelerate the design of open source chipsets with the AIB 2.0 specification. The conversation also touched on our efforts to provide better support for SystemVerilog using open source tools and to create a dynamic stratified scheduler implementation in Verilator.

Check out the podcast here. The conversation with Rob starts at 7:03.

SymbiFlow FPGA Interchange Format to Enable Interoperable FPGA Tooling

By Blog

This post was originally published at Antmicro.

Field Programmable Gate Arrays (FPGAs) have been around for several decades, but historically development of toolchains targeting specific platforms was done in separate ecosystems and driven by the vendors themselves. Only in recent years, the development of vendor-neutral open source toolchains has revealed the need of having an abstraction layer to describe and define an FPGA architecture through a standard format.

FPGA toolchains are not trivial as they comprise several elements which themselves can be quite complex: roughly speaking, you can divide the process of “compiling” FPGA-targeted code in a Hardware Description Language (HDL) into three stages: synthesis, place and route, bitstream generation. A standard format could provide a common description of the various architectures and serve as a bridge between the multitude of open source and closed proprietary tools that deal with the entire process or parts thereof, including the open source Yosys for synthesis and VtR and nextpnr for place and route, to relevant vendor tooling from Xilinx, Intel, Lattice, QuickLogic, etc.

The introduction of a common format enables a shared methodology where specific building blocks are simply interchangeable. With that in mind, together with Google we started the FPGA Interchange Format project within the SymbiFlow initiative, bringing forth a unified framework that, by lowering the entry barriers, lets developers swiftly move from one tool to another with virtually no effort. As part of our collaboration with Google, Antmicro is now developing the Interchange format definition and related tools which aim to become a development standard the FPGA industry has been in need of.

Interchange format: components

The Interchange format provides three key descriptions to describe an FPGA and interact with the various tools involved:

  • Device resources: defines the FPGA internal structure as well as the technological cell libraries describing FPGA logic blocks (basic blocks like flip-flops and complex like DSP cells),
  • Logical netlist: post-synthesized netlist compatible with the Interchange,
  • Physical netlist: collection of all placement locations and physical routing of the nets and resources produced by the place and route tool.

One of the main challenges behind the creation of a standard format, specifically for the device resources, lies in the definition of the line between generalization and specificity of an FPGA architecture, as each device architecture variant may have some individual features that can be difficult to generalize in the context of other variants.

For this practical reason, the FPGA Interchange format in its current form focuses on the only architecture type in mainstream use on the market today, namely island-based (also called tile-based) FPGAs: two-dimensional arrays of reconfigurable logic blocks, hard blocks, switch blocks and input-output blocks.

This allows the standard to reach a level of universality and conciseness which makes it easy to work with, adopt and implement.

Interchange format: implementation

After determining what the Interchange format should describe, the next step was to define how to best implement the format itself. The choice fell on a well-supported, open source and fast serialization protocol – Cap’n Proto.

Cap’n Proto allows a great efficiency in terms of run-time and on-disk memory occupation, given also the huge amount of elements that are present in an FPGA device, such as wires and connections, that need to be stored in the device database. The protocol enables a concise, well-defined and, if used correctly, a backward compatible architecture and netlist format description.

The framework uses the Cap’n Proto schema language whose implementations exist in many of the most common programming languages such as C++, Python, Java and Rust. This gives a good chance of future interoperability with other tooling that will inevitably emerge if the standard is successful.

On top of the FPGA Interchange schema definitions, a Python-based library was created to interface with the schema itself, and provides functionalities to read and write device databases, logical netlists and physical netlists, as well as utilities to convert from one representation to another. It is often the case where a physical netlist needs to be inspected and analyzed, and a Cap’n Proto serialized netlist can be easily converted to its YAML or JSON human-readable equivalents.

Interchange format: how it works

As previously mentioned, the FPGA Interchange format aims at lowering the barriers and building bridges between different place and route tools that can read and write using the same convention.

In this sense, the major milestone of the Interchange format was to have the production and exchange of the physical netlist between one place and route tool and another.

To reach this milestone, nextpnr was chosen as the first place and route tool to adopt the Interchange format. In the past few months, we extended nextpnr with FPGA Interchange format capabilities and currently the tool is able to place and route basic designs for the Xilinx 7-series and Lattice Nexus FPGA families using the format.

To achieve initial support for Xilinx devices, the vendor’s own extremely interesting RapidWright framework has also been introduced to the flow, and it is specifically used to write the device database in the Interchange format, consisting of all the device information.

Additionally, RapidWright is able to read and write the physical netlists to generate design checkpoint files that can be opened in Xilinx’s Vivado tool.

Example flow

The default open source flow for Xilinx devices uses Yosys to synthesize the design and VPR or nextpnr for place and route. The last step – bitstream generation uses the FPGA Assembly FASM format to generate the file used for programming the FPGA. FASM is a textual format specifying which FPGA feature should be enabled or disabled. Its textual nature makes it easy to analyze and experiment with. VPR supported this format natively, and nextpnr has been extended to support it as a part of the interchange format support work.

Supported SymfbiFlow interchange tooling

Now, by using the interchange format, you can create your flow from building blocks, with the possibility to use a different tool (either open source or proprietary) for each step.
A sample, somewhat involved flow which illustrates this mix-and-match nature of interchange-capable tooling may look as described below.

For processing any design, you need the FPGA device description files. These are generated in the following matter:

  • RapidWright generates the device description in the Interchange format,
  • The device description is translated by a dedicated script into the data-format suitable for nextpnr. The script will be eventually integrated into nextpnr enabling it to read the interchange format device description natively,

The device description has to be generated only once, and will normally be distributed with the toolchain installation package so that the user will not have to bother with this part.

With the device architecture in place, a digital design can be processed with the toolchain:

  • Yosys reads design’s Verilog code, synthesizes it and writes a synthesized netlist
  • The synthesized netlist is translated into a logical netlist by another script. The script will eventually be integrated into Yosys as the interchange backend,
  • Nextpnr places and routes the design and outputs a physical netlist,
  • RapidWright reads the physical and logical netlists and produces a Design Checkpoint (DCP) for Vivado,
  • Vivado can be used to read the DCP.

Keep in mind this is just one of many possible flows. It is used to test the interchange format interoperability between different tools.

This flow example shows how the Interchange creates a bridge between an open source flow with Yosys and nextpnr, and a closed source one using Vivado – demonstrating the possibility of interchanging tools thanks to a shared format.

To ensure the Interchange format works as intended using all the various currently supported tools, we have developed an FPGA Interchange tests suite, which provides tests that expose device features and functionalities.

To push forward the adoption of the format, the effort is being currently transferred from the SymbiFlow project into the CHIPS Alliance, whose goal is to build an open source ASIC/FPGA ecosystem – including cores, I/O IPs, interconnect standards as well as digital and analog tooling – to radically transform the ASIC/FPGA design landscape.

Apart from allowing various existing tools to interoperate and share development efforts today, the Interchange format is a natural addition to the CHIPS Alliance in that it opens up smart ways to rapidly design and prototype new FPGA architectures, reduce the iteration times to implement, or add support to a place and route tool for a new architecture.

Plans for the coming months

Besides nextpnr, there are other open source place and route tools slated to adopt the Interchange format as well, such as the Versatile Place and Route (VPR) from the Verilog-to-Routing project (VtR).

Originally intended to perform architectural design exploration to support research in the FPGA field, VtR – and specifically VPR – can be used to place and route designs on real devices as well, such as the Xilinx 7-series and QuickLogic architectures, but only using the VPR data model and device description, as it does not yet support the Interchange format.

One of the next milestones in the development of the Interchange format is the full native support of the format within VPR, therefore enabling something that was previously impossible: performing place and route using different tools interchangeably; jumping, for instance, from VPR placement output to nextpnr routing, allowing for faster improvements in algorithms.

Those benefits will extend to not only VPR and nextpnr, but to any other closed source tools, or new open source ones that adopt and implement the Interchange format.

In fact, having a standard Interchange format at the tooling developers’ disposal lowers the barriers to developing new open source tools in this area and, as example use cases, enable new approaches to partial dynamic reconfiguration, or the exploration of different place and route algorithms.

Automatic SystemVerilog Linting in GitHub Actions with Verible

By Blog

This post was originally published at Antmicro.

With the recent advances in open source ASIC development tools such as Verible, it has become easier to automate tasks and boost developer productivity. The Verible linter is a static code analysis tool that has been helping us and our collaborators to spot and fix stylistic errors and bugs in SystemVerilog code.

CI/CD for smaller backlog and better test reliability

As part of our work within the newly established CHIPS Alliance SystemVerilog subgroup, Antmicro has made further steps to facilitate SystemVerilog workflows with Verible, by providing an easy to use Verible Linter GitHub Action. Combined with another open source tool called Reviewdog, the action allows you to easily perform automatic code style checks and code review.

Diagram depicting Verible integration with Github Actions

Using it is as easy as adding a few lines to a workflow in the .github/workflows directory. For basic usage, just add the action with a github_token parameter to your current workflow:

    - uses: chipsalliance/verible-linter-action@main
    with:
    github_token: ${{ secrets.GITHUB_TOKEN }}

For a more tailor-made setup, it is easy to configure the action by:

  • excluding selected files from the linting process,
  • providing a configuration file that will be used with --conf-file option of the linter,
  • choosing the form of the output,
  • specifying any extra arguments for the linter.

With this straightforward solution, any GitHub-hosted open-source or private project can inform commiters about the issues detected in their code, as you can see in the picture below. Of course, creating similar setups in private installations and other repository systems is also possible, and Antmicro offers the services to develop the necessary tooling, integrations and provide support and guidance.

Screenshot of Verible Github Actions

The action uses a GitHub Token assigned to every workflow run individually. There’s no need to create personal access tokens, and you can use it in any repository, no matter if it uses a public, private, or enterprise plan.

Developers can discuss each problem separately, by creating responses to the comments made by the GitHub Actions bot. Marking a conversation as resolved will let others know that the issue has already been taken care of.

If, instead of automatic code review, you wish to have a log with all the issues, you can omit the github_token parameter. You can see the setup in action on the Ibex RISC-V Core used by the OpenTitan project below:

Verible CI setup used by OpenTitatn project

Software developers have been using such automated solutions to facilitate cross-team and cross-company collaboration, taking away the daily pains of coordinating between large teams while improving the ability to detect faults early. Instant, targeted feedback helps both the committers and the reviewers.
Working together with Google and other CHIPS Alliance members we are making the benefits of automated, software-driven development in distributed environments and the cloud available to hardware developers. A wide range of applications for the Verible linter action can be devised, from faster pull requests reviews, to isolating erroneous portions of code.

Coming next

We’re working on adding this action to the Ibex repository. The next step will be preparing a GitHub Action with the Verible formatter, which will allow to not only find problems but automatically suggest changes.

Open Source Custom GitHub Actions Runners with Google Cloud and Terraform

By Blog

This post was originally published at Antmicro.

In order to fulfill our internal and our customers’ needs, we have developed and successfully deployed an open source custom GitHub Actions runner that allows us to mix the GitHub default and your custom hardware and software. The runner software itself operates within a Google Cloud Platform project, spawns Compute Engine instances and orchestrates the build, providing a number of interesting advantages that were needed in our ASIC and FPGA-related work. As is typical for us, we have released all the necessary components as open source – read on to learn how the solution works, the benefits it offers and how to build and deploy this software in your organization (which we can also help with as part of our commercial support and engineering services).

As we continue our push for more software-driven hardware development as part of our work within CHIPS Alliance and RISC-V, we see an increasing need for scalable and flexible CI solutions that can be used with a mix of open source and proprietary components. By building on top of existing infrastructure such as GCP, GH Actions and Terraform, it’s possible to achieve noticeable performance gains, better traceability and runtime isolation for some of the advanced use cases we are helping our customers tackle (we have highlighted some of those aspects previously in a blog note earlier this year).

Architecture and scalability

By default, the software leverages virtual infrastructure created within a GCP project in order to perform builds, consisting of a coordinator instance (which receives jobs from GitHub backend and reports back progress), a virtual subnetwork and dynamically spawned worker instances.

custom runners in GPC architecture diagrams

In order to reduce the cognitive strain and encapsulate complexity, we’ve prepared a Terraform module that can be used to provision these necessary components easily and make it possible to store the configuration of individual coordinators according to the principles of Infrastructure as Code.

Once provisioned and configured, the coordinator is able to spawn instances of any type available within Google Compute Engine. In projects where cost optimizations are a necessity, it is possible to configure the coordinator to spawn preemptible instances.

The setup is flexible enough that you can self-host it in your internal infrastructure and connect custom hardware such as FPGA platforms to the coordinator machine, which will then spawn per-job virtual machines with hardware attached using a pass-through mechanism. This capability makes it possible to build automated hardware in the loop testing platforms – something we see as an increasingly useful feature especially given the growing portfolio of our server-oriented platforms like Scalenode and the FPGA-based DC-SCM.

Antmicro Scalenode platform with Artix-7 boards connected

Additional insights into the build capabilities

When creating increasingly complex CI pipelines, we also need a better overview of the builds we are performing. In order to address this requirement, our runner introduces a couple of changes that at the first glance might seem minor, but contribute to a significant improvement in readability.

Firstly, in the build logs, each line of output is prefixed with a green or red-colored timestamp, depending on whether the output is coming from standard output or standard error. As a measure to augment the output of Bash scripts, lines that come out as a result of the “set -x” option are highlighted as well, providing a yet another visual cue for the reader.

Another important improvement is related to performance analysis and resource usage. To get more insight into our complex and often resource-heavy builds (related to the fact that activities such as place and route or physical layout may take many hours if not days to complete), each worker collects a performance graph using sargraph that can be later retrieved using the upload-artifact action.

This kind of rich context for our CI infrastructure is a necessity for our work related to e.g. to the FPGA interchange format or dynamic scheduling in Verilator whose goals are to enable radical improvements in FPGA and ASIC design. We are doing this by visiting previously unexplored avenues and encouraging a broad collaboration with the research community, customers and partners to achieve a step function progress in areas which are only now starting to experience the explosion of creativity related to new open source and software-driven approaches.

custom runners in GPC screenshot

Apart from supercharging the logs with visual metadata, we’ve addressed the issue of log storage. Google’s BES and ResultStore APIs lend themselves to this use case, allowing the upload of rich metadata associated with the builds and providing a pretty front-end for viewing the logs. Thanks to that, we have an alternative place where logs, artifacts and the aforementioned performance graphs can be stored and viewed independently of GitHub. An example of how this works can be seen in the SymbiFlow examples repository by clicking on any tick associated with a commit and scrolling down to the bottom. This functionality was implemented using our open source distant-bes and distant-rs libraries.

custom runners in GPC screenshot

Cloud-assisted ASIC design

The ongoing effort to enable cloud-assisted ASIC design as well as new development methodologies for FPGAs is bound to accelerate going forward, given the high interest among our customers and groups such as CHIPS Alliance.

We always look forward to projects with partners who want to make full use of modern (and open) tooling and environments which, with knowledge and experience, we’re confident to modify for better, scalable and vendor-neutral system development.

Open Source SystemVerilog Tools in ASIC Design

By Blog

This post was originally published at Antmicro.

Open source hardware is undeniably undergoing a renaissance whose origin can be traced to the establishment of RISC-V Foundation (later redubbed RISC-V International). The open ISA and ecosystem, in which Antmicro participated since the beginning as a Founding member, has sparked many open source CPU implementations but also new tooling, methodologies and trends which allow for more collaborative and software driven design.

Many of those broader open hardware activities have been finding a home in CHIPS Alliance, an open source organization we participate in as a Platinum member alongside Google, Intel, Western Digital, SiFive and others, whose goals explicitly encompass:

  • creating and maintaining open source ASIC and FPGA design tools (digital and analog)
  • open source core and uncore IP
  • interconnects, interoperability specs and more

This is in perfect alignment with Antmicro’s mission, as we’ve been heavily involved with many of the projects inside of and related to CHIPS, providing commercial support and engineering services – and assistance in practical adoption for enterprise deployments.

As of this time, a range of everyday design, development, testing and verification tasks are already possible using open source tools and components and are part of our and our customer’s everyday workflow. Other developments are within reach given a reasonable amount of development, which we can provide based on specific scenarios. Others still are much further away, but with dedicated efforts inside CHIPS in which we are involved together with partners like Google and Western Digital there is a pathway towards a completely open hardware design and verification ecosystem. This will eventually unlock incredible potential in new design methodologies, vertical integration capabilities, education and business opportunities – but until then, practical value can already be extracted today for many scenarios such as simulation, linting, formatting, synthesis, continuous integration and more, and Antmicro can help you do that.

Building a SystemVerilog ecosystem in CHIPS

Some of the challenges towards practical adoption of open source in ASIC design have been related to the fact that a significant proportion of advanced ASIC design is done in SystemVerilog, a fairly complex and powerful language in its own right, which used to be poorly supported in the open source tooling ecosystem. Partial solutions like SystemVerilog to Verilog converters or paid plugins existed, but direct support lagged behind, making open source tools for SystemVerilog a difficult sell previously.

This has been fortunately changing rapidly with a dedicated development effort spearheaded by Google and Antmicro. Projects in this space include Verible, Surelog, UHDM and sv-tests which we have been developing as well as integrating with existing tools like Yosys, Verilator under the umbrella of the SymbiFlow open source FPGA project, and which are now officially being transferred into the CHIPS Alliance to increase awareness and build a broader SystemVerilog ecosystem around them. In this note, we will walk you through the state of the art in new SystemVerilog capabilities in open source projects, and invite you to reach out to see how CHIPS Alliance’s SystemVerilog projects can be useful to you today or in the near future.

Diagram depicting SystemVerilog tools

Verible

The Verible project originated at Google, and its main mission is to make SystemVerilog easily and quickly parsable for a wide variety of applications mostly focusing on developer tools.

Verible is a set of tools based on a common SystemVerilog parsing engine, providing a command line interface which makes integration with other tools for daily usage or CI systems for automatic testing and deployment a breeze.

Antmicro has been involved in the development of Verible since its initial open source release and we now provide a significant portion of current development efforts, helping adapt it for use in various open source projects or commercial environments that use SystemVerilog. One notable user is the security-focused OpenTitan project, which has driven many interesting developments and provides a good showcase of the capabilities, being completely open source, well documented, fairly complex and used in real applications.

Linter

One of the most common use cases for Verible is linting. The linter analyzes code for patterns and constructs that are deemed undesirable according to the implemented lint rules. The rules follow authoritative style guides that can be enforced on a project or company level in various SystemVerilog projects.

The rules range from simple ones like making sure the module name matches the file name to more sophisticated like checking variable naming conventions (all caps, snake case, specific prefix or suffix etc.) or making sure the labels after the begin and end statements match.

A full list of rules can be found in the Verible lint documentation and is constantly growing. Usage is very simple:

$ verible-verilog-lint --ruleset all core.sv 
core.sv:3:11: Interface names must use lower_snake_case naming convention and end with _if. [Style: interface-conventions] [interface-name-style]

The output of the linter is easy to understand, as the way issues are reported to the user is modeled after popular programming language compilers.

The linter is highly configurable. It is possible to select the rules for which the compliance will be checked, some rules allow for detailed configuration (e.g. max line length).

Rules can also be selectively waived in specific files or at specific lines or even by regex matching. In addition, some rules can be automatically fixed by the linter itself.

Formatter

The Verible formatter is a complementary tool for the linter. It is used to automatically detect various formatting issues like improper indentation or alignment. As opposed to the linter, it only detects and fixes issues that have no lexical impact on the source code.

The formatter also comes with useful helper scripts for selective and interactive reformatting (e.g. only format files that changed according to git, ask before applying changes to each chunk).

A toolset that consists of both the linter and the formatter can effectively remove all the discussions about styling, preferences and conventions from all pull requests. Developers can then focus solely on the technical aspects of the proposed changes.

$ cat sample.sv
typedef struct {
bit first;
        bit second;
bit
   third
        ;
  bit fourth;
bit fifth; bit sixth;
}
 foo_t;


$ verible-verilog-format sample.sv
typedef struct {
  bit first;
  bit second;
  bit third;
  bit fourth;
  bit fifth;
  bit sixth;
} foo_t;

Indexer

The Verible parser itself can be relatively easily used to perform many other tasks. One of the interesting use cases is generating a Kythe compatible indexing database.

Indexing a SystemVerilog project makes it very easy to collaborate on a project remotely.
It is possible to navigate through the source code using nothing else than just a web browser.

The Kythe integration can be served on an arbitrary server, can be deployed after every commit in a project, etc. A showcase of the indexing mechanism can be found in our GitHub repository. The demo downloads the latest version of the Ibex core, indexes it, and deploys it to be viewed on a remote machine.
The results can be viewed on the example index webpage.

Demo of SystemVerilog indexing

Indexing is widely adopted for many larger open source software projects.
Thanks to Verible it is now possible to do the same in the world of open source HDL designs, and of course private, company-wide deployments like this are also possible.

Surelog and UHDM

SystemVerilog is a powerful language, but it is also complex. That is why so far no open source tools have been able to support it in full. Implementing it separately for each project such as the Yosys synthesis tool or the Verilator simulator would take a colossal amount of time, and that’s where Surelog and UHDM come in.

Surelog, originally created and led by Alain Dargelas, aims to be a fully-featured SystemVerilog 2017 preprocessor, parser, and elaborator. It’s a modern tool and thus follows the current version of the SV standard without unnecessary deviations or legacy baggage.

What’s interesting is that Surelog is only a language frontend designed to integrate well with other tools – it outputs an elaborated design in an intermediate format called UHDM.
UHDM stands for Universal Hardware Data Model, and it’s both a file format for storing hardware designs and a library able to manipulate this format. A client application can access the data using VPI, which is a standard programming interface for SystemVerilog.

What this means is that the work required to create a SystemVerilog parser only needs to be done once, and other tools can use that parser via UHDM. This is much easier than implementing a full SystemVerilog parser within each tool. What’s more, any improvements in the unified parser will provide benefits for all client applications. Finally, any other parser is free to emit UHDM as well, so in the future we might see e.g. a UHDM backend for Verible.

Just like in Verible’s case, both Surelog and UHDM have recently been contributed into CHIPS Alliance to drive a broader adoption. We are actively contributing to both projects, especially around the integrations with tooling such as Yosys and Verilator and practical use in open source and customer projects.

Recent Antmicro contributions adding UHDM frontends for Yosys and Verilator enabled Ibex synthesis and simulation. The complete OpenTitan project is the next milestone.

The Surelog/UHDM/Yosys flow enabling SystemVerilog synthesis without the necessity of converting the HDL code to Verilog is a great improvement for open source ASIC build flows such as OpenROAD’s OpenLane flow (which we also support commercially). Removing the code conversion step enables the developers to perform e.g. circuit equivalence validation to check the correctness of the design.

More information about Surelog/UHDM and Verible can be found in a dedicated CHIPS Alliance presentation that was recently given by Henner Zeller, Google’s Verible lead.

UVM is in the picture

No open source ASIC design toolkit can be complete without support for Universal Verification Methodology, or UVM, which is one of the most widespread verification methodologies for large-scale ASIC design. This has also been an underrepresented area in open source tooling and changing that is an enormous undertaking, but working together with our customers, most notably Western Digital, we have been making progress on that front as well.

Across the ASIC development landscape, UVM verification is currently performed with proprietary simulators, but a more easily distributable, collaborative and open ecosystem is needed to close the feedback loop between (emerging) open source design approaches and verification. Verilator is an extremely popular choice for other system development use cases but it has historically not focused on UVM-style verification. Other styles of verification, such as the very interesting and popular Python-based cocotb framework maintained by FOSSi Foundation have been enabled in Verilator – we write about our own work around that in a dedicated blog note. But support for UVM, partly due to the size and complexity of the methodology, has been a notably absent.

One of the features missing from Verilator but needed for UVM is SystemVerilog stratified scheduling, which is a set of rules specified in the standard that govern the way time progresses in a simulation, as well as the order of operations. In short, a SystemVerilog simulation is divided into smaller steps called time slots, and each time slot is further divided into multiple regions. Specific events can only happen in certain regions, and some regions can reoccur in a single time slot.

Until recently, Verilator had implemented only a small subset of these rules, as all scheduling was being done at compilation time. Spearheading a long-standing development effort within CHIPS Alliance, in collaboration with the maintainer of Verilator, Wilson Snyder, we have built is a proof-of-concept version of Verilator with a dynamic scheduler, which manages the occurrence of certain events at runtime, extending the stratified scheduling support. More details can be found in Antmicro’s presentation for the inaugural CHIPS Alliance Deep Dive Cafe Talk.

Another feature required for UVM is constrained randomization, which allows generating random inputs to feed to a design in order to thoroughly test it. Unlike unconstrained randomization, which is already provided by Verilator, it allows the user to specify some rules for input generation, thus limiting the possible value space and making sure that the input makes sense. Work on adding this to Verilator has already started, although the feature is still in its infancy. There are many other features on the roadmap which will eventually enable practical UVM support – stay tuned with our CHIPS Alliance events to follow that development.

What next?

Support for SystemVerilog parsers, for the intermediate format, and for their respective backends and integrations with various tooling as well as for UVM is now under heavy development. If you would like to see more effort put into a specific area, reach out to us at contact@antmicro.com. Antmicro offers commercial support services to extend the flows we’ve briefly presented here to various practical applications and designs, and to effectively integrate this approach into people’s workflows.

Adding to this our cloud expertise, Antmicro customers can benefit from a complete and industry-proven methodology scalable between teams and across on-premise and cloud installations, transforming chip design workflows to be more software-driven and collaborative. To take advantage of open source solutions with tools like Verilator, Yosys, OpenROAD and others – tell us about your use case and we will see what can be done today.

If you are interested in collaborating on the development SystemVerilog-focused and other open hardware tooling, join CHIPS Alliance and participate in our workgroups and help us push innovation in ASIC design forward.