All Posts By


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).


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.

SkyWater Technology Joins CHIPS Alliance to Further Efforts to Make Chip Design and Production More Accessible

By Announcement

SkyWater furthers collaboration with CHIPS Alliance members on open source shuttle projects

SAN FRANCISCO, Sept. 16, 2021 – CHIPS Alliance, the leading consortium advancing common and open hardware for interfaces, processors and systems, today announced that SkyWater Technology (NASDAQ: SKYT) has become a member of the organization. SkyWater provides custom development, volume manufacturing and advanced packaging services for a wide range of silicon, including solutions based on the free and open RISC-V instruction set architecture (ISA).

“The pace of open source hardware innovation is continuing to heat up. We are proud to have helped make it possible to design, verify and manufacture SoCs that have been entirely developed with open source technologies, from process technology to intellectual property and the automation environment,” said Ross Miller, Vice President, Strategic Marketing & Business Unit at SkyWater Technology. “CHIPS Alliance has already generated strong momentum with its work and we look forward to collaborating with the organization and its membership to take open source innovation to new heights.”

In May 2021, SkyWater and fellow CHIPS Alliance member Efabless launched the chipIgnite program to bring chip design and fabrication to the masses. SkyWater’s open source 130 nm CMOS platform will be used to fabricate chips for the chipIgnite program. The automotive-grade mixed-signal platform is well suited for IoT and edge computing as it is designed to support both digital and analog circuits with embedded non-volatile memory for a wide range of SoC architectures. Open source designs and private commercial designs that include non-open source IP are both eligible to participate in the program. 

The chipIgnite program extends SkyWater’s work with Google, eFabless, Antmicro and the OpenROAD project, among other partners, on the Open MPW Shuttle Program. The multi-project wafer (MPW) program provides fabrication for fully open source projects using SkyWater’s Open Source PDK. Costs for fabrication, packaging, evaluation boards and shipping are covered by Google. During the first round of the shuttle run, called MPW-ONE, 40 open source designs were selected to be fabricated at no cost to designers; 60 percent of those designs were submitted by first-time ASIC designers. The second phase, MPW-TWO, is in progress now and the parts and assembled boards will be shipped to the project owners by the end of the year. 

“The chipIgnite and MPW programs that SkyWater has enabled perfectly align with CHIPS Alliance’s mission to make chip design more accessible, while significantly reducing the cost of creating and fabricating chips,” said Rob Mains, General Manager at CHIPS Alliance. “We are pleased to have SkyWater formally join CHIPS Alliance as we continue to collaborate to break down the barriers of chip design.”

About the CHIPS Alliance

The CHIPS Alliance is an organization which develops and hosts high-quality, open source hardware code (IP cores), interconnect IP (physical and logical protocols), and open source software development tools for design, verification, and more. The main aim is to provide a barrier-free collaborative environment, to lower the cost of developing IP and tools for hardware development. The CHIPS Alliance is hosted by the Linux Foundation. For more information, visit

About the Linux Foundation

The Linux Foundation was founded in 2000 and has since become the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Today, the Foundation is supported by more than 1,000 members and its projects are critical to the world’s infrastructure, including Linux, Kubernetes, Node.js and more. The Linux Foundation focuses on employing best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, visit

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
    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


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.


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


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
typedef struct {
bit first;
        bit second;
  bit fourth;
bit fifth; bit sixth;

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


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

Advanced Co-simulation with Renode and Verilator: PolarFire SoC and FastVDMA

By Blog

This post was originally published at Antmicro.

Co-simulating HDL has been possible in Renode since the 1.7.1 release, but the functionality – critical for hardware/software co-development as well as FPGA use cases – is constantly evolving based on the needs of our customers like Google and Microchip as well as our work in open source groups including CHIPS Alliance and RISC-V International. To quickly recap, by co-simulation we mean a scenario where a part of the system is simulated in Renode but some specific peripheral or subsystem is simulated directly from HDL, e.g. Verilog. To achieve this, Renode integrates with Verilator, a fast and popular open source HDL simulator, which we are helping our customers adopt as well as expanding its capabilities to cover new use cases. Peripherals simulated directly from HDL are typically called Verilated peripherals.

Why co-simulate?

Co-simulation is a highly effective approach to testing IP cores in complex scenarios. HDL simulation is typically much slower than functional simulation, so to cut down on development turnaround time you can partition your design into a fixed part that you can simulate fast using Renode and the IP you are developing that you can co-simulate using Verilator. Renode offers a lot of ready-to-use components – for which you do not need to have a hardware description – which can be put together to provide a complete system to test new IP core designs.

Co-simulation in Renode so far

For more than a year now, Renode has supported using AXI4-Lite and Wishbone buses for the Verilated peripherals’ communication with the rest of the system. As can be seen with the Verilated UART examples included with Renode, these can be used not only to receive data from, but also to send data to the peripheral. Additionally, because Renode can simulate external interfaces, you can easily open a window for such a UART (with showAnalyzer command during simulation) and the whole interaction is driven by UART’s TX and RX signals.

Diagram depicting FastVDMA co-simulation

The riscv_verilated_liteuart.resc script shows the interaction between the system based on the VexRiscv CPU implemented in Renode and the UART based on an HDL model simulated with Verilator that together enable users to work with Zephyr’s shell interactively.

In these examples, however, all the communication is initiated from Renode’s side by either reading from or writing to UART. There is no way for the peripheral to trigger the communication, which limited use-cases where the co-simulation could have been used.

New co-simulation features

Thanks to our work with Microchip and Google, since Renode 1.12 new features are available in the VerilatorPlugin; the most important change is introducing the ability for a Verilated peripheral to trigger communication with other elements of the system. The Renode API was expanded to accommodate the new features. There are now two new actions in the co-simulating communication which enable a Verilated peripheral to initialize communication with Renode by sending data to or requesting data from the system bus.

Support for the AXI4 bus was also added. This is different from the AXI4-Lite bus, which only implements a subset of AXI4 features. The Verilated peripheral can either act on AXI4 bus as a controller that requests accesses (therefore utilizing these new Renode API actions) or as a peripheral (in the AXI4 bus context) that is only requested to take some action.

How it works

Creating a Renode agent (which handles an HDL model’s connection with Renode) with a role chosen for your peripheral is as simple as including an appropriate header and connecting signals. For example, FastVDMA acts as a controller on AXI4 bus with the following code in a file creating its Renode agent:

#include "src/buses/axi-slave.h"
VDMATop *top;

void Init() {
    AxiSlave* slaveBus = new AxiSlave(32, 32);
    slaveBus->aclk = &top->clock;
    slaveBus->aresetn = &top->reset;

    slaveBus->awid = &top->io_write_aw_awid;
    slaveBus->awaddr = (uint32_t *)&top->io_write_aw_awaddr;

    // Connecting the rest of the signals to the bus

Another new feature is the ability to connect the Verilated peripheral through multiple buses. For example, now it’s possible to have a peripheral connected to both AXI4 and AXI4-Lite buses, which enables even more complex HDL models to be tested with Renode. This is the case of the FastVDMA, which is connected this way:

#include "src/buses/axi-slave.h"
#include "src/buses/axilite.h"

RenodeAgent *fastvdma;

void Init() {
	AxiLite* bus = new AxiLite();
	AxiSlave* slaveBus = new AxiSlave(32, 32);

	// Initializing both buses’ signals

	// Init eval function
	bus->evaluateModel = &eval;
	slaveBus->evaluateModel = &eval;

	// Init peripheral
	fastvdma = new RenodeAgent(bus);



Fast Versatile DMA (FastVDMA) is a Direct Memory Access controller designed with portability and customizability in mind. It is an open source IP core developed by Antmicro in 2019 that is written in Chisel. It is a very versatile DMA controller because of the range of supported buses. It can be controlled through an AXI4-Lite or Wishbone bus while the data can be transmitted through either an AXI4, AXI4-Stream or Wishbone. Since its inception it has been used in a number of projects, e.g., bringing a GUI to krktl’s snickerdoodle. For more information it’s best to head to the original blog note about FastVDMA.

Expanding the PolarFire SoC ecosystem

Through Antmicro’s long-term partnership with Microchip, Renode is a vital part of the PolarFire SoC developer experience. Microchip customers are using the Renode integration with the vendor’s default SoftConsole IDE to develop software for the PolarFire SoC platform and it’s development board, the Icicle Kit.

PolarFire Icicle with Antmicro's HDMI breakout board

With the latest co-simulation capabilities, developers are able to explore a combination of hard and soft IP, developing their FPGA payload and verifying it within Renode. This allows them to work on advanced projects, from graphic output support similar to the one we implemented for snickerdoodle with FastVDMA (possibly employing our open-hardware HDMI board for Icicle Kit), through advanced FPGA-based crypto solutions, to design-space exploration and pre-silicon development, with the debugging and testing capabilities native to Renode.

To see how Renode allows you to simulate complex setups with multiple co-simulated IP blocks, see our tests of Verilated FastVDMA plus Verilated RAM.

It’s worth noting that as these blocks are isolated and interconnected only via Renode, you can easily prepare setups in which peripherals use different busses to connect. This gives you an ability to focus on the interesting details and to prepare your systems from building blocks more easily.

Commercial support

If you’d like to speed up the development of your ASIC or FPGA solution using the advantages of advanced co-simulation, Antmicro offers commercial support and engineering services around Renode, Verilator and other tools, as well as FPGA and ASIC design, hardware, software and cloud services. We work with organizations like CHIPS Alliance and RISC-V International enable a more software-driven hardware ecosystem based by open source. For a full list of our open source activity, head to our open source portal.

Progress on Building Open Source Infrastructure for System Verilog

By Blog

By Rob Mains, General Manager of CHIPS Alliance

SystemVerilog is a rich hardware design description and verification language that is seeing increased usage in industry. In the second Deep Dive Cafe Talk by CHIPS Alliance on July 20, Henner Zeller, who is an software developer with Google, provided an excellent in depth technical talk on building out an open source tooling ecosystem around SystemVerilog to provide a common framework that can be used by both functional simulation applications as well as logic synthesis. In case you missed the live presentation, you can watch it here

Henner started the talk by providing background and motivation for the work on expanding the tooling available for SystemVerilog. It was noted that SystemVerilog is being used by a large cohort in industry, but there is little awareness that open source tools supporting SystemVerilog exist. Of note is that SystemVerilog is analogous to C++ as is Verilog to C in terms of language robustness and complexity. As such, developing a framework and metric-based scorecard to measure the quality of applications supporting this is of importance. A key aspect of adoption of SystemVerilog and associated open source tooling is that it works out of the box. Subsequently, the so-called sv-tests framework was created by Antmicro and Google – and subsequently transferred to CHIPS Alliance – as a unit test system for SystemVerilog tools to assess the quality of the parsing and handling of different attributes of the language. To incentivize participation, a leader board has been created to show quality of results. 

The talk also provided an overview of the different parsers Surelog, sv-parser, and Verible, along with discussion of their positive attributes and limitations. This was followed by presentation of UHDM (Unified Hardware Data Model) – a data model allowing transferring parsed and elaborated SystemVerilog between frontend and simulation or synthesis software.

An example integration of the UHDM based flow developed collaboratively by CHIPS members Google and Antmicro was presented next. The development aims to integrate the UHDM handling capability with Verilator simulator and Yosys synthesis tools. The work is done publicly in CHIPS Alliance’s GitHub repositories. The UHDM integration tests repository collects all the pieces of the system and allows running the integration tests.

The development and measurement of different applications to parse SystemVerilog and robustly represent in a common data representation will do much to ensure the development of a solid framework for construction of different design automation tools. 

The next CHIPS Alliance Deep Dive Cafe is on Tuesday, Aug. 10 at 4 p.m. PT. Experts from Intel and Blue Cheetah will present on PHYS, protocols, EDA, and heterogeneous integration as well as latest developments on die-to-die interfacing. You can register for the event here.

What You Need to Know About Verilator Open Source Tooling

By Blog

By Rob Mains, General Manager of CHIPS Alliance

Verilator is a high performance, open source functional simulator that has gained tremendous popularity in its usage and adoption in the verification of chip design. The ASIC development community has widely embraced Verilator as an effective, often even superior alternative to proprietary solutions, and it is now the standard approach in RISC-V CPU design as the community has worked to provide Verilator simulation capabilities out of the box. CHIPS Alliance and RISC-V leaders Antmicro and Western Digital have been collaborating to make Verilator even more useful for ASIC design purposes, working towards supporting industry-standard verification methods in a completely open source flow.

On June 15 at the inaugural CHIPS Alliance Deep Dive Cafe Talk, Karol Gugala, an engineering manager with Antmicro, provided an excellent in-depth technical talk on extending Verilator towards supporting universal verification methodology, UVM. The event was well attended, and is now also available on YouTube.

Karol started the talk by providing motivation for the improvement and expansion of the System Verilog design environment, and in particular the importance of UVM to offer a common verification framework. He covered the current limitations of Verilator relative to its handling of UVM, and the goal of the community to more robustly support UVM and also System-Verilog as a design language, both of which are efforts Antmicro is deeply involved with as part of its work within CHIPS Alliance with other CHIPS partners. In the talk, Karol provided in-depth details of work that has been done to handle UVM.

The focus of the work summarized by Karol’s talk was the comparison of static event scheduling already existent in Verilator to dynamic scheduling which is required for event driven simulation, specifically event and time awareness. This necessitated a new event scheduling approach in Verilator to be implemented. The new scheduler is an option that the user can activate as a runtime switch. Future work includes: clocking blocks, assertions, assertions, class parameters, integration with UHDM, and further runtime optimization. Full UVM support for the SweRV RISC-V cores and OpenTitan – also based on a RISC-V implementation, Ibex – are two key goals. A detailed overview of how System Verilog statements are evaluated as members of different processes was provided. As an initial implementation, each process now runs in a separate thread, with processes and threads communicating via standard IPC synchronization protocols. Scheduling of the threads / processes is left to the OS scheduler, and further work in the project will include more involved scheduling techniques.

You can read more about dynamic scheduling in Verilator at Antmicro’s blog, and test all the new features of Verilator with examples of designs and some GitHub Actions-based CI simulations (based on Antmicro’s public repo).

The next talk in the CHIPS Deep Dive Cafe Series is the AIB Deep Dive + Opportunities Presented By Intel on Tuesday, Aug. 10 at 8 a.m. PT. You can register for the event here.