Skip to main content
Category

Blog

Raviewer – An Open Source Tool for Debugging Video Pipelines

By Blog

This post was originally published at Antmicro.

Antmicro is involved in many projects where video processing is the key focus – from SDI-enabled AV equipment, through multi-camera robotics systems, biometric identifications devices to VR and medical cameras.
When working with off-the-shelf video sources (or prerecorded test datasets) it is easy to assume that a camera always just spits out a good looking picture and all you have to do is run your high-level algorithms to process it.

Raviewer's logo

Things are wildly different when – like us – you’re actually involved in building camera systems, which is often required for custom, innovative applications that push the limits of what is possible. In fact, when you start working on a lower level, say by capturing the data with an FPGA board or when you are implementing camera drivers for new cameras or new platforms, the number of moving parts you are juggling before you get usable video make debugging pretty difficult. That is why we developed a new open source image analysis tool called Raviewer to assist in such cases, and as with many other tools originally created for our internal needs while developing products for our customers, we released it to help reduce frustration related to working with difficult engineering problems.

Processing video data 101

The theory behind image data is very simple. Most of the capture devices use one of the popular predefined formats (an RGB, YUV or BAYER variant). In addition to that, images have a width and a height. In practice, before reaching the user, the video data typically goes through many layers of processing, and even a small misconfiguration in the pipeline can render the image useless.
There are several things that can go wrong. The receiver (the FPGA pipeline or the sensor driver) needs to be configured to match the data provider (e.g. a camera sensor). The match needs to be bit-perfect. The problems we usually encounter include reversing the bit order, mismatched image format configuration (e.g. RGB instead of YUV, or RGB24 instead of RGB32), switched endianness, incorrect dimensions, etc.

In the world of embedded platforms that we typically deal with, most vendors (like Nvidia or NXP) equip their chips with dedicated video capture blocks which do some processing and conversion themselves, providing an extra layer of complication. Similar issues arise when working with proprietary codecs and other closed SoC building blocks which more often than not involve binary blobs which make debugging even harder.

Diagram depicting difficult to debug pipeline

Debugging issues with image data

Experience shows that debugging visual problems is best done with visual tools. The very first step to solving the problem needs to be acquisition and a proper identification of the data. Once the exact format of the data is known, the problem becomes much easier to fix.

Diagram depicting easy to debug pipeline

Raviewer is an open source tool for handling arbitrary binary data and visualizing it using selected parameters. Changing the parameters gives visual cues that help identify the data. Let’s take a look at an example.

Assume that we captured a file called unknown_data, which we know to contain an image – but we do not know anything about it. The usual first step (without the right tools) would be to look at the dump of the data

$ hexdump unknown_data | head -n 20
00000000  ff 7f 13 ff ff 7e 12 ff  fb 7d 18 ff f9 7b 16 ff 
00000010  f5 7b 21 ff f3 79 1f ff  e9 71 22 ff e3 6b 1c ff
00000020  da 65 21 ff da 65 21 ff  d5 65 2f ff d4 64 2e ff
00000030  c4 5f 33 ff b9 54 28 ff  ac 4d 2b ff a9 4a 28 ff
00000040  99 49 37 ff 91 41 2f ff  83 3f 30 ff 80 3c 2d ff
00000050  76 3f 37 ff 72 3b 33 ff  66 37 3b ff 62 33 37 ff
00000060  58 2d 38 ff 57 2c 37 ff  53 2b 37 ff 53 2b 37 ff
00000070  52 2c 37 ff 52 2c 37 ff  4f 2d 35 ff 4f 2d 35 ff
00000080  54 2e 37 ff 53 2d 36 ff  52 2d 33 ff 52 2d 33 ff
00000090  53 2e 34 ff 52 2d 33 ff  51 2c 30 ff 4f 2a 2e ff
000000a0  51 2a 2f ff 51 2a 2f ff  50 29 2d ff 51 2a 2e ff
000000b0  55 2c 2e ff 56 2d 2f ff  56 2d 2f ff 55 2c 2e ff
000000c0  4f 2c 30 ff 4f 2c 30 ff  4f 2c 30 ff 4e 2b 2f ff
000000d0  4c 29 2d ff 4b 28 2c ff  4c 29 2d ff 4d 2a 2e ff
000000e0  50 2d 31 ff 50 2d 31 ff  50 2d 31 ff 50 2d 31 ff
000000f0  4f 2c 30 ff 4e 2b 2f ff  4c 29 2d ff 4c 29 2d ff
00000100  48 2c 2d ff 47 2b 2c ff  46 2a 2b ff 45 29 2a ff
00000110  45 29 2c ff 45 29 2c ff  46 2a 2d ff 46 2a 2d ff
00000120  45 2a 2d ff 45 2a 2d ff  45 2a 2d ff 44 29 2c ff
00000130  43 27 2d ff 43 27 2d ff  42 26 2c ff 42 26 2c ff

We can clearly see some kind of data is there, but very little beyond that. Raviewer can help with that. Importing the file into Raviewer renders the following:

Visualizing binary data to images with Ravwier

Now we can see something that resembles an image, or is it one at all? Typically to arrive at some meaningful conclusion in your research it’s good to experiment a bit. The first step will be to change the format we interpret the data with to see if we can get a better result.

Visualizing binary data to images with Ravwier

Changing the format to a 32 bit RGB format starts showing some shapes. The image seems to be showing some interlacing-like artifacts though. That usually means the line width interpretation is not correct yet. Let’s see if that can be fixed.

Visualizing binary data to images with Ravwier

Much better. However the colors still seem to be a little bit off, in addition, some artifacts near the edges can be seen. The color format is still not correct, let’s try other formats, keeping what we already know about the image constant.

Visualizing binary data to images with Ravwier

Switching endianness produces a correct, good looking image.

Raviewer proved to be useful in our recent projects, for example in developing the FPGA debayering core in which we implemented a demosaicing system that converts raw data obtained from CCD or CMOS sensors.

In addition to that, at Antmicro we believe that proper continuous testing is needed to keep things working. That’s why Raviewer comes with a command line interface that can be used in CI pipelines.

Boost your video processing platform with Raviewer

The described use case is just a small taste of what Raviewer is capable of. Our goal is to make sure that Raviewer can be used in other projects for more complex and detailed analysis. In order to achieve that we are working on several enhancements, which among others, would enable working with v4l2 cameras directly or use neural networks to interpret the data and e.g. detect the image format.

SATA Design Implementation on FPGAs with Open Source Tools

By Blog

This post was originally published at Antmicro.

Real-world FPGAs designs often require high rate transmission protocols such as PCIe, USB and SATA which rely on high speed transceivers for external communication. These protocols are used to interface with various devices such as graphics cards and storage devices, and many of our clients reach out to us specifically because they need the flexibility, high-throughput and low-latency characteristics of FPGAs.

In particular, for customers that deal with high data volumes (which is very common in video applications), implementing SATA to communicate and transfer data with e.g. an SSD hard drive is a must.

Since Antmicro believes in an open source, vendor neutral approach to FPGAs, today we will describe how to build a SATA-enabled system using a completely open source flow, including the hardware platform, FPGA IP as well as, perhaps most importantly, tooling which we have been developing as part our bigger effort within CHIPS Alliance.

Origin and motivation

Antmicro is a pioneer in a software-driven approach to developing FPGAs. On top of new hardware description languages, open source IP and software that have been gaining traction in the FPGA space, one necessary missing element has been open source tooling. Open tools allow a workflow more familiar to software developers, who are used to just downloading their toolchain without having to log in anywhere or managing licenses.

Moreover, open tools provide the great advantage of easy to set up CI systems that keep track of regressions and allow more efficient and robust development.

Some of our forward-looking customers such as Google require these kinds of workflows to take full control of their development toolchain, for various reasons: securitydevelopment productivityscale. Others, like QuickLogic, who thanks to the cooperation with us are the first ever FPGA vendor company to fully embrace open source tools, are looking to deliver a more tailored experience to their own customers, which is easier to do based on open source.

To prove the viability of open source FPGA tools, being able to implement high-speed interfaces to verify how the toolchain handles high-speed transceivers is key; thus, a fully open source SATA is a very good target, especially that an open source core, LiteSATA, was available in our favorite open source SoC generator for FPGAs, LiteX. What was missing was a hardware platform, putting it all together, and – of course – tools.

Hardware setup

The SATA design we developed is meant to run on top of a Nexys Video board from Digilent, featuring an Artix7 200T Xilinx FPGA, coupled with custom expansion board connected through the FMC connector and hosting an M.2 SSD module. Thanks to the FMC connector on the Nexys Video we achieved a relatively simple and modular hardware setup.

The FMC expansion board, developed by Antmicro, is fully open-sourced and available on GithHub.

Open source SATA hardware setup

FPGA gateware and system block diagram

The FPGA design is generated with the LiteX SoC builder and the main components that we used are:

  • The VexRiscV RISC-V CPU
  • The LiteDRAM controller to communicate with the DDR Memory
  • The LiteSATA core to communicate with the SSD module on the custom expansion board
  • a UART controller to be able to control the system from the host

Moreover, the software running in the SoC includes a simple BIOS that can perform SATA initialization and basic read and write operations of the sectors in the SSD drive.

Running open source SATA diagram

Open source toolchain

The SATA setup proves that high speed protocols can be enabled on mainstream FPGAs such as Xilinx 7-series with an open source toolchain, with Yosys for synthesis and VPR for place and route. The LiteSATA IP core makes use of so-called GTP hard blocks, and in fact one of the main challenges we dealt with here was enabling these hard blocks in the Artix-7 architecture definition to get an end-to-end open source toolchain.

Other than enabling more coverage of popular FPGAs, much of our current FPGA toolchain effort goes into increasing the interoperability of tools like VPR and nextpnr as well as their proprietary counterparts to enable a more collaborative ecosystem which would enable the community – including universities, commercial companies, FPGA vendors and individual developers – to tackle the ambitious goal of open source FPGAs together.

For more information on the FPGA interchange and how much value it brings to the open source FPGA tooling refer to the dedicated Antmicro blog note. In the future, once that work is at a more advanced stage, LiteSATA will be one of the first example designs to be tested with the FPGA interchange-enabled tools.

Building and running the setup

The FPGA SATA design is available in the symbiflow-examples repository and can be built with the open toolchain, and run on the hardware setup described above.

After following the instructions to install the toolchain and preparing the environment, run the following to build the LiteX SATA design:

cd xc7
make TARGET=”nexys_video” -C litex_sata_demo

When the bitstream is generated, you can find it in the build directory under litex_sata_demo/build/nexys_video.

To load the bitstream on the Nexys Video board you can use the OpenFPGALoader tool, which has support for the board.

Once the bitstream is loaded on the FPGA, you can access the BIOS console through the UART connected to your host system and run the following (note that X depends on the assigned USB device):

picocom --baud 115200 /dev/ttyUSBX

When the LiteX BIOS gives you control, you need to perform the SATA initialization before being able to read and write sectors on the drive. See the output below:
Running LiteSATA with SymbiFlow in console

Future goals

The work on enabling the SATA protocol in a fully open source flow was one of the steps on the way towards supporting PCIe in the toolchain which will unlock even more advanced use cases. PCIe can be used for a variety of purposes, such as connecting external graphic cards or accelerators to an FPGA design, and generally enable even faster transmission rates from and to the FPGA chip.

Open Source FPGA Platform for Rowhammer Security Testing in the Data Center

By Blog

This post was originally published at Antmicro.

Our work together with Google and the world’s research community on detecting and mitigating the Rowhammer problem in DRAM memories has been proving that the challenge is far from being solved and a lot of systems are still vulnerable.
The DDR Rowhammer testing framework that we developed together with an open hardware LPDDR4 DRAM tester board has been used to detect new attack methods such as Half-Double and Blacksmith and all data seems to suggest this more such methods will be discovered with time.

But consumer-facing devices are not the only ones at risk. With the growing role of shared compute infrastructure in the data center, keeping the cloud secure is critical. That is why we again teamed up with Google to bring the open source FPGA-based Rowhammer security research methodology to DDR4 RDIMM used in servers by designing a new Kintex-7 platform for that use case specifically, to foster collaboration around what seems to be one of the world’s largest security challenges.

Hardware overview

Open source data center Rowhammer tester board

The data center DRAM tester is an open source hardware test platform that enables testing and experimenting with various DDR4 RDIMMs (Registered Dual In-Line Memory Module).

The main processing platform on this board is a Xilinx Kintex-7 FPGA which interfaces directly with a regular DDR4 DIMM connector. The new design required more IOs compared to the LPDDR version, which was a major driving factor for changing the Kintex-7 FPGA package from 484 to 686 pins.

Basing the test platform on the Kintex-7 FPGA allowed us to implement a completely open source memory controller – LiteDRAM – fully within the FPGA just like for the LPDDR case. The system can thus be modified and re-configured on both hardware and software level to freely sculpt memory testing scenarios, providing developers with a flexible platform that can be easily adjusted to new data center use cases. Our previous design was targeting a single channel from a single LPDDR4 IC, featuring specially-designed modules to cover for the fact that LPDDR memories aren’t meant to particulary “modular”. For the data center use case however, as reflecting the more standardized nature of that space, the new board can handle a full-fledged, off-the-shelf DDR4 RDIMM with multiple DRAM chips.

As in the LPDDR4 version, the new board features different interfaces to communicate with the FPGA, such as RJ45 Gigabit Ethernet and a Micro USB console. Additionally, there is an HDMI output connector for development purposes. Other features include:

  • A JTAG programming connector
  • A microSD card slot and 12 MBytes flash memory
  • HyperRam – external DRAM memory that can be used as an FPGA cache.

What is worth stressing here is that unlike LPDDR4, DDR4 modules don’t have to be custom made and are available to buy off the shelf – an advantage that greatly expands the potential applicability and outreach of the platform.

Block diagram depicting open source data center Rowhammer tester platform

Using open source to transform data centers

The DRAM tester described here is meant, of course, to be used with the Antmicro open source Rowhammer testing framework mentioned in the opening of this blog note. The list of devices discovered to be vulnerable to attacks so far is significant, and the new design will help to cover a huge chunk of data center oriented memory modules.

The DRAM testing capabilities of the Rowhammer tester are not limited to DDR4 RDIMM memories and LPDDR4 only. Plans for 2022 include support for LPDDR5 and DDR5, which will result in more hardware and collaborations, and hopefully more mitigation techniques. With an open source DRAM controller at the heart, the framework offers potential of collaboration around building Rowhammer mitigations into the controller itself, using the transparency of open source IP to stay one step ahead of the potential attacks.

The recent data center security work is part of our wider effort to push open source tooling, methodologies and approach to data center customers. In a similar vein, within the LibreBMC group in OpenPOWER Foundation, we are leading a project to replace ASIC-based BMC (board management controllers) with soft CPUs running on popular and low-cost FPGA platforms. LibreBMC will be a completely transparent security and management solution both in terms of hardware and software and includes two boards compatible with OCP’s DC-SCM standard based on the Xilinx Artix-7 and Lattice ECP5 FPGAs respectively.

Complementing our software capabilities in scaling huge workloads and building robust design, development, test and CI, simulation and verification pipelines, our data center oriented platforms also include Scalenode, which shows how open source hardware can be used to build modular servers based on both ARM (Raspberry Pi 4 CM) and RISC-V (ARVSOM).

Our open source based services ranging from ASIC and hardware design through IP and software development lets us offer comprehensive help to a wide array of data center customers, to improve their security, development speed and collaboration capacities.

The DDR testing platform in a broader context

The data center DRAM tester is further proof that the open source hardware trend spearheaded by Antmicro can bring practical value, especially in terms of security and collaboration capability. Developing a completely open framework, configurable down to the DRAM controller itself, has led us to some fantastic collaborations and sparked ideas which would otherwise be impossible to implement. Both the CHIPS Alliance, the OpenPOWER Foundation and RISC-V International have a keen interest in taking the memory controller work forward, potentially leading up to ASIC-proven DDR controller IP.

An open source IP ecosystem which we are actively participating in could revolutionize how ASIC and FPGA systems are built. It is one of the key components in a wider push for a more open source, pragmatic and software-centric approach to hardware that we are helping shape at the global level by participating in policy-making initiatives in the EU and US.

On a more down-to-earth note, the data center platform is yet another permissively licensed open source board in our arsenal, and can serve as a good reference design for Kintex-7 projects which we are happy to customize and build upon for other areas or types of research for our customers.

Software-driven ASIC Prototyping Using the Open Source SkyWater Shuttle

By Blog

This post was originally published at Antmicro.

The growing cost and complexity of advanced nodes, supply chain issues and demand for silicon independence mean that the ASIC design process is in need of innovation. Antmicro believes the answer to those challenges is bound to come from the software-driven, open source approach which has shaped the Internet and gave rise to modern cloud computing. Applying the methodologies of software design to ASICs is however notoriously viewed as difficult, given the closed nature of many components needed to build chips – tools, IP and process design kits, or PDKs for short, as well as the slow turnaround of manufacturing.

The open source, collaborative SkyWater PDK project, combined with the free ASIC manufacturing shuttles running every quarter from Google and efabless, has been filling one of those gaps. Add to it open source licensed ASIC design tools we are helping develop as part of CHIPS Alliance as well as massive parallelization capabilities offered by the cloud and what you get is an ASIC design ecosystem at the verge of a breakthrough. To effect this change, together with Google, efabless, SkyWater and others we are working on more developments, including letting the shuttle designs benefit from software-driven hardware productivity tools such as LiteX and Renode (which we are currently helping the SkyWater shuttle effort to adopt), as well as new and exciting developments in the process technology itself.

If you want to participate in making ASIC design history, let us show you why and how the shuttle program is the way to do that. And by the end of this article, hopefully you will want to participate in the next, fourth shuttle with the submission deadline at the end of this year.

chip tapeout

SkyWater PDK – some background

In May 2020 Google and SkyWater Technology Foundry released the first ASIC proven open source PDK. The PDK targets the 130 nm process which, while not state-of-the-art, is still in widespread practical use, especially in mixed-signal and specialized designs.

The PDK release involved restructuring the original code and data and properly documenting all the available cells in the PDK. This operation was performed in a collaboration between a group of industrial and academic partners, with Antmicro’s effort focused mostly on developing tools for automatic PDK structuring and documentation.

An open source PDK was a key missing piece in end-to-end open source ASIC development, but in itself would not allow the average developer to feel the change. To enable developers to work with the PDK in practice and build fully open source chips with fast turnaround that is necessary to breed the necessary innovation, Google funded the Open MPW Shuttle Program operated by efabless, a fellow CHIPS Alliance member. The program assumes the applying projects are fully open source and based on a permissive license, targets the 130 nm SkyWater process and uses open source ASIC toolchain. Projects accepted in the program are then manufactured and the authors receive their packaged ASICs without any additional costs – production, packaging, testing and delivery is all covered for.

The program is a great opportunity for any developer wanting to develop open source ASICs and contribute to the emerging open source ASIC community. The first shuttle program attracted 37 projects, including:

  • Five RISC-V SoCs
  • A cryptocurrency miner
  • A robotic app processor
  • A template SoC based on OpenPOWER
  • An Amateur Satellite Radio Transceiver
  • Analog/RF IPs
  • Four eFPGAs
  • Antmicro’s AES-128 core integration.

We have been assisting customers expressing the desire to participate in the SkyWater shuttle in assessing the feasibility of their designs, creating the necessary workflows and adapting the tools involved to their particular needs.

Our engineering services can be used to enhance your development teams with the ability to use open source tools more effectively and integrate with your infrastructure in a way which allows you to benefit from the open source’s capabilities while not disrupting your internal workflows unnecessarily.

In total, over 100 designs have been sent to fabrication so far, many authored by teams with a predominantly software background. With over 2500 users in the SkyWater open source PDK slack, this is truly a community in the making.

Most of the designs in the shuttles use the Caravel harness design which implements a RISC-V CPU with some base peripherals, OpenRAM generated memory, an I/O ring and a user area where developers can place their designs. The harness design is meant to be a fixed block / starting point which significantly lowers the entry level for the ASIC developers, but as such is also subject to evolution to better answer the needs of the shuttle participants, which we will describe later in the note.

Open source ASIC tools

The core part of the PDK shuttle process uses the OpenLane toolchain, a flow based on the OpenROAD project, also a part of CHIPS Alliance. The toolchain implements all the steps required to generate a production-ready ASIC layout (GDS) from an RTL design.

ASIC design with SkyWater Shuttle diagram

Since production is the most expensive and time consuming part of the process, testing and validation are key stages in need of innovation, and the experiences learned from the SkyWater shuttle effort are invaluable.

Under the auspices of CHIPS Alliance, Google, Western Digital and Antmicro are leading the work on enabling fully open source SystemVerilog development, testing and validation. The work focuses on a number of design flow aspects, including:

All these are meant to improve the development experience and benefit from the inherent scalability and reusability of open source tools to offer practical value for teams building new ASIC designs.

Adoption of LiteX for Caravel

Open source design tools constitute one aspect of fully open source ASIC design. The other aspect, just as important as tooling, is open source, high-quality, reusable IP cores, and indeed the very rules of the SkyWater shuttle program encourage developers to open source their design and reuse existing cores.

At the core of the shuttles is the Caravel harness. To improve the shuttle’s user experience and let the community benefit from a wider array of off-the-shelf tools and cores, we are assisting with the ongoing effort of adopting the Caravel design to be based on LiteX.

LiteX, a widely known open source SoC generator, will make it possible for more open source cores to be integrated with ASIC designs, ultimately lowering the entry barrier for software engineers. It comes with multiple ready to use cores, including an open source DRAM controller used in the Rowhammer test platform we described some time ago. This alternative harness, whose development you can track in a dedicated GitHub repository, will open the door to more contributions from the LiteX community and allow us to use a bunch of tools that we have already integrated, like our open source simulation framework, Renode.

Renode’s hardware/software co-development capabilities

The LiteX framework provides developers with an easy way to experiment with various different CPU cores. Testing a system against many possible cores, often running complex software, makes validation no trivial task.

Renode, Antmicro’s open source development framework, features advanced SW/HW/FPGA/ASIC co-simulation capabilities and has been directly integrated with LiteX to generate the necessary configurations that correspond to the hardware system. Renode supports a multitude of CPU, I/O IP, sensor and network building blocks, both native to LiteX and otherwise, allowing its users to simulate the entire platform design before implementation, i.e. in the pre-silicon stage.

Renode addresses the profound challenge of testing complex software, running it on various CPUs and using custom peripheral cores at the same time. Developers can make use of Renode’s ability to co-simulate with Verilator or with physical hardware, reducing the simulation time of SoC systems that utilize custom IP cores.

Back in September, Antmicro presented a case of co-simulating the popular Xilinx Zynq-7000 SoC running Linux with a verilated FastVDMA core, and of course co-simulation with platforms like the PolarFire SoC is something we have been steadily improving on with our partner Microchip.

A similar kind of development methodology will be possible with the new Caravel harness.

Taking that HW/SW co-design workflow to its natural consequence, as showcased by our work with Google, Dover Microsystems and others, Renode allows developers to build SW-oriented hardware faster than HDL and benefit from the flexibility known from software development cycles where iterations happen in a matter of days. Recently, Renode has been extended with support for RISC-V vector instructions which translates into a further improvement of the development process of machine learning algorithms in open source ASICs.

Scaling into the cloud and hybrid setups

Building and testing ASIC designs is often a time and resource intensive task. The open source tooling approach, endorsed by the SkyWater shuttle program, possesses an important advantage over any proprietary perspective – it allows for infinite scaling of compute resources as there are neither licensing costs nor other license related limitations involved.

Developments around distributed and scalable cloud based CI/CD systems like self-hosted GitHub Actions runners in GCP, a collaboration between Antmicro and Google, are providing the ecosystem with new options for reliable, fast testing and deployment of ASIC designs. Cloud based CI systems can be built to combine both closed and open source solutions, providing hybrid solutions that fill the gaps of either approach. And on a more general level, scalable and accessible CI/CD systems facilitate collaboration between large and geographically distributed teams of developers.

New developments

SkyWater PDK is being constantly improved, extending the possibilities for future designs. One of the recent add-ons to the PDK is a ReRAM library which can be used to develop non-volatile memories using the SkyWater 130nm technology.

Further SkyWater PDK development plans include extending the PDK portfolio with 180nm, 90nm and 45nm technology processes – stay tuned for upcoming developments in that space!

Participate in shuttle runs

Three shuttle runs have already happened, and thanks to Google’s commitment as well as the overwhelming interest from business, research and government institutions, the project will continue through 2022 and most likely beyond. The 4th shuttle run is currently open and will be accepting submissions by December 31, 2021.

For projects that, for any reason, cannot be open sourced or submitted within the timeline of the open shuttle, a private shuttle called ChipIgnite has been created.

Open Source Debayerization Blocks in FPGA

By Blog

This post was originally published at Antmicro.

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

Diagram depicting debayerization process

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

Open source debayerization

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

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

System structure

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

Diagram depicting dmosaicing wrapper

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

Open source FPGA IP cores for vendor-neutral solutions

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

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

How Google is Applying Machine Learning to Macro Placement 

By Blog

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

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

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

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

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

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

Improving the OpenLane ASIC Build Flow with Open Source SystemVerilog Support

By Blog

This post was originally published at Antmicro.

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

One of CHIPS Alliance’s projects, the DARPA-funded OpenROAD, has created the necessary tooling to build open source ASIC-oriented flows such as OpenLane and OpenFASoC, becoming one of the central elements of the open ASIC ecosystem. The OpenROAD project, led by prof. Andrew Kahng from University of California San Diego, aims at a fully end-to-end, RTL-GDSII flow, providing accessibility and collaboration options that are often not available for proprietary tools.

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

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

Why open source tools for ASIC development?

The hope for open source ASIC flows like OpenLane is to provide multiple benefits:

  • enable new, less conventional approaches
  • provide more capabilities of vertical integration
  • encourage more software-driven and AI-assisted workflows
  • use the infinite scalability of the cloud without worrying about licensing costs

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

Open Source SystemVerilog support in OpenLane

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

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

Diagram depicting openlane flow

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

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

Diagram depicting surelog/uhmd -> yosys

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

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

Building and testing OpenLane with SystemVerilog support

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

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

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

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

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

export IMAGE_NAME=<docker image name>
make test

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

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

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

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

Early adoption services for open source in ASIC design

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

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

Recap of the Fall 2021 CHIPS Alliance Workshop

By Blog

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

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

Each of these talks provided informative, technical details of key aspects of the work underway by members of CHIPS Alliance who are working in an open, collaborative fashion. Of particular interest are the following topic areas:

Porting Android to RISC-V

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

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

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

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

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

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

FPGA Tooling Interoperability with the FPGA Interchange Format

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

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

OmniXtend Scalability and LPC

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

Open Source NVME IP with AI Acceleration

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

Analog design automation: OpenFASOC and ALIGN

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

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

Open Source DDR Controller Framework for Mitigating Rowhammer

By Blog

This post was originally published at Antmicro.

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

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

Rowhammer attack diagram

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

The Rowhammer Tester platform

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

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

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

Platform architecture

Rowhammer test platform architecture diagram

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

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

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

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

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

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

New DRAM PHYs

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

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

LPDDR4 test platform

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

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

What’s next?

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

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

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

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

By Blog

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

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