Skip to main content


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.

Efabless Launches chipIgnite with SkyWater to Bring Chip Creation to the Masses

By Blog
  • Program includes a pre-designed carrier chip and automated open source design flow from Efabless
  • SkyWater’s open source SKY130 process is the first node to be used to fabricate chips for the program
  • Initiative removes access barriers by significantly reducing cost and the need for deep semiconductor experience to design chips

Efabless, a community chip creation platform, today announced the launch of its new chipIgnite program to bring chip design and fabrication to the masses and a collaboration with SkyWater Technology for the first node supported in the program. The chipIgnite program expands upon the SKY130-based open source chip manufacturing program sponsored by Google and supports private commercial designs that include non-open source IP. This initiative represents another step forward in the industry to broaden access to chip design by giving people the ability to more easily create and fabricate chips.

The first shuttle in the chipIgnite program will support fabrication of student projects as part of the EE272B course in the Electrical Engineering department at Stanford University for senior undergraduate and graduate students.

The new program also has industry support from organizations including QuickLogic and the CHIPS Alliance.

“CHIPS Alliance is a major champion of open source hardware design and associated design automation tools. I am excited to see the chipIgnite program offered by Efabless to include many different collaborative IP developers to prove new ideas. The platform alleviates the barriers to entry into chip design and allows for ready exploration of many concepts,” said Rob Mains, general manager of CHIPS Alliance.

Read the full announcement at Efabless:

Antmicro’s ARVSOM RISC-V Module Announced

By Blog

This post was originally published at Antmicro.

We are excited to announce the ARVSOM – Antmicro’s fully open source, RISC-V-based system-on-module featuring the StarFive 71×0 SoC. Using the RISC-V architecture, which Antmicro has been heavily involved in since the early days as a Founding Member of RISC-V International, the SoM is going to enable unprecedented openness, reusability and functionality across different verticals.

We are excited to announce the ARVSOM – Antmicro’s fully open source, RISC-V-based system-on-module featuring the StarFive 71×0 SoC. Using the RISC-V architecture, which Antmicro has been heavily involved in since the early days as a Founding Member of RISC-V International, the SoM is going to enable unprecedented openness, reusability and functionality across different verticals.


Open source-driven innovation

Since its conception, Antmicro has been enabling its customers to tap into the technological freedom that is inherent in open source. We’ve been developing cutting-edge industrial and edge AI systems using vendor-neutral and customizable solutions as well as actively developing and contributing to the tooling ecosystem, improving processes and unlocking even more system design options – often in alignment with our efforts driving RISC-V International and CHIPS Alliance. Targeted at a range of different use cases and enabling unmatched flexibility, ARVSOM is the latest product and example of Antmicro’s expertise in creating practical and easily modifiable technologies using open source.

Based on StarFive 71×0

Sitting at the heart of ARVSOM is the StarFive 71×0 system-on-chip – the first Linux-capable RISC-V SoC that is intended for mainstream, general-purpose edge applications and is expected to be used in millions of devices to be built on the open source RISC-V ISA. The SoC is also used in the BeagleV StarLight development platform (GitHub repo) which has just been shipped to beta users, including Antmicro, who will be verifying its robustness and reliability in real life use cases, while the development community focuses on further expanding the RISC-V software support. The SoC features a dual core U74 CPU from our partner and RISC-V pioneer SiFive, two AI accelerators: the open source NVDLA and SiFive’s Neural Network Engine, 1 MIPI DSI and 2 MIPI CSI interfaces, HDMI, Gigabit Ethernet, dual ISP, USB 3.0, while the production version of the SoC to be released later in the year will also have PCI Express.

Compatible with Scalenode for server room applications

The SoM will be compatible with our server-oriented Scalenode platform, released earlier this month, originally designed as a baseboard for the Raspberry Pi 4 Compute Module. Used together, Scalenode and ARVSOM will enable building easily scalable and flexible infrastructures consisting of clusters of small RISC-V-based compute units, with as many as 18 Scalenode boards fitting in a 1U rack. ARVSOM will also work with other Raspberry Pi CM 4 baseboards, opening the door to a host of solutions and custom devices to be built with it right away.

ARVSOM in Renode

You can already start software development with our ARVSOM and the BeagleV StarLight SBC thanks to support in Renode, our open source simulation framework. The two have joined an array of platforms and sensors that can be simulated in our open source framework for system development and testing. You can freely co-develop hardware and software in Renode’s virtual environment, with the code behaving exactly the way it would on real hardware. Renode can also be used throughout the development lifecycle to enable continuous testing and integration, as well as prototyping new solutions based on RISC-V, as it features extensive support of this open source ISA. You can read more about the latest updates in Renode in the version 1.12 announcement blog note.

Our SoM is in development and will be gradually unveiled throughout the year with the increasing StarFive 71×0 SoC availability.

ARVSOM can be customized and integrated into your project. We have been helping our customers embrace the groundbreaking RISC-V architecture and enable them to reap the benefits of having an advanced system based on vendor-neutral, future-proof and robust technologies. Get in touch with us at if you need a modern product that you have full control over.

Dynamic Scheduling in Verilator – Milestone Towards Open Source UVM

By Blog

This post was originally published at Antmicro.

UVM is a verification methodology traditionally used in chip design which has historically been missing from the open source landscape of verification-focused tooling. While new, open source approaches to verification have emerged that include the excellent Python-based Cocotb (that we also use and support) maintained by FOSSi Foundation, not everyone can easily adopt it, especially in long-running projects and existing codebases that use a different verification approach. Leading the efforts towards comprehensive UVM / SystemVerilog support in open source tools, we have been gradually completing milestones, getting closer to what will essentially be a modular, collaboration-driven chips design methodology/workflow. Some examples of our activity in this space include enabling open source synthesis and simulation of the Ibex CPU in Verilator/Yosys via UHDM/Surelog, and the most recent joint project with Western Digital in which we have developed dynamic scheduling in Verilator.

Verilating non-synthesizable code

The work is a part of a wider, long-term effort that, besides Western Digital, has involved other fellow CHIPS Alliance members such as Google, to develop UVM / SystemVerilog support in open source tools. To get closer to this goal, this time we have introduced an improvement to Verilator – an open source tool that is great at doing what it was originally designed to do, that is simulating synthesizable code, but hasn’t been enabling its users to convert non-synthesizable code and run fully fledged testbenches written in Verilog/SystemVerilog. The biggest challenge to opening that possibility turned out to be Verilator’s original scheduler running everything sequentially, which in general is not a bad approach but can get you only so far without actually executing the code in parallel.

Dynamic scheduling in Verilator

To run proper UVM testbenches in Verilator, we had to be able to properly handle language constructs specifically designed for use in simulation. Those features include delay statements, forks, wait statements and events. To achieve all of this, we needed to add a proof-of-concept dynamic scheduler to Verilator.

How dynamic scheduling in Verilator works

Instead of grouping code blocks of the same type as the original scheduler does, the dynamic scheduler separates the code into many runnable blocks and then creates and spawns a process for each of them (when they are due to be executed). To deal with it we created a new process, which translates to a new high level thread for each initial blockalways blockforever block, each block in the fork statement etc. This allows us to pause the execution of one block and continue the execution of other blocks. Blocks can be paused when they encounter simulation control statements like:

  • The wait statement (e.g. wait (rdy == 1); or wait (event_name.triggered))
  • Waiting for an event (e.g @event_name;)
  • A delay (#10;)
  • Or even a join statement after fork (joinjoin_any – join_none is also supported, however it is not used to control the execution per se)

All of the statements listed above are not supported in Verilator’s original scheduler, so to be able to dynamically control the execution of those already dynamically spawned sub-processes, a way to react to changes in signal/events states needed to be implemented. We did it by wrapping the primitive types used for storing signal values in objects using higher abstraction levels, which now allows us to attach other processes to monitor values of specific signals and execute an arbitrary callback when a signal changes. Note that this is a mechanism used internally to implement the flow control statements and is not visible to the user writing Verilog code.

One additional thing that had to be re-written and adapted to the dynamic scheduler was the way non-blocking assignments are handled.

With a scheduler that is aware of the simulation time and other flow control statements, the same approach originally used by Verilator could not be applied anymore. A way to properly schedule assignments, and execute them in the proper moment was a crucial step in getting all of this to work.

Note that the features described above are the ones that are immediately visible to users of Verilator with the dynamic scheduler. This is however only the tip of the iceberg when it comes to the amount of internal changes needed to be done in Verilator.

Example usage

To present the usage of all the new Verilator features we have created a public GitHub repository with a number of example designs and GitHub Actions-based CI simulating them.

The examples range from single feature examples to more complex scenarios simulating a system with two UARTs sending data between each other.

The UART testbench example uses all the newly added features. It spawns a thread for every simulated UART block and each thread feeds the UART IP that is being tested with the predefined data (the “hello world” string in our example).

The UART block reads the data from an AXI stream interface, serializes it and sends it over the TX line.

The received data is available on the output AXI Stream bus.

Each testbench thread introduces a random delay between consecutive data chunk transmission.

The threads are synchronized using SystemVerilog events – e.g. once the data is fed into the UART block over the AXI stream interface, a thread is triggering an event informing the other part of the thread that the data is being transmitted by the IP.
Once transmission is done, another event is triggered informing the first thread that the IP is ready for a new data chunk.

Once all the test data is transferred between both tested UART instances, the threads are joined and data correctness is validated.

Next steps, future goals

This ongoing project is a big step towards UVM support in open tools as it not only removes a number of limitations in this area but also opens the door to future developments – which include a number of SystemVerilog features oriented towards verification which were earlier out of scope since open source UVM verification wasn’t on the horizon. Together with the effort to support SystemVerilog in Verilator using UHDM which is part of another ongoing project, in CHIPS Alliance we continue to work towards enabling open source design verification for everyone, which will revolutionize the way chips are built.