GSoC23 — Final Project Report

Table of Contents

Introduction

All good things come to an end, and so does my Google Summer of Code (GSoC) project about implementing the SDF INTERCONNECT feature in Icarus Verilog. This feature is important if you want to perform timing accurate Verilog simulations of an ASIC (application-specific integrated circuit). Once a design has been hardened, the delays can be extracted from the actual physical layout, as can be seen in the example of this RISC-V CPU:

Macro of PicoRV32

PicoRV32 RISC-V CPU generated via OpenLane

The many things I learned during this project will be valuable to me for a long time to come. These include practical skills such as working on a large codebase, learning more about Verilog simulators and Verilog features that you don't often stumble across, but also soft skills like collaboration, communication with my mentors, and self-management.

In the following, I will explain what this project was about and which goals I managed to achieve.

Project Information

  • Title: Improving SDF support in Icarus Verilog
  • Mentors:
    • Tim Edwards
    • Mohamed Shalan
    • Cary R
  • Description:

    When you design a digital circuit, you want to make sure that all timings are correct, even post-layout. Therefore, the gate level netlist is annotated with delays extracted from the layout. The file format that contains these delay and timing information is called Standard Delay Format (SDF). Icarus Verilogs' SDF implementation has shortcomings in the following categories:

    1. Wire / Interconnect delays
    2. Conditional path delays
    3. Timing checks

    Work needs to be done on these categories, all while supporting related bugs as we more completely test gate level simulations. With the work proposed here, I would like to improve Icarus' SDF support to simulate SDF back-annotated timing simulations for the open SKY130 PDK. The deliverables for this project are:

    1. Implementing the SDF INTERCONNECT feature
    2. Writing tests for the regression suite
    3. Example of a SDF back-annotated timing simulation using the SKY130 PDK

In short: My goal was to make the SDF INTERCONNECT feature usable within Icarus Verilog, with the overall target of simulating simple designs with interconnection delays from OpenLane. Below you can see the work I did and the goals I achieved :)

My Work During GSoC

Documentation Rework and Cleanup

The work during this initial period did not directly contribute towards the completion of the tasks, but proved invaluable to my later work. During this time I learned a lot about how Icarus Verilog is structured and how everything fits together.

Implementing SDF INTERCONNECT

During this second time period I completed the main part of my GSoC project: implementing the SDF INTERCONNECT feature.

Let's see which of my tasks I have completed:

  • ✅ Implementing the SDF INTERCONNECT feature

I have implemented the SDF INTERCONNECT feature to the best of my knowledge. There may linger some bugs here and there, but I was able to simulate a complete RISC-V CPU with interconnection delays enabled, so it is definitely capable.

  • ✅ Writing tests for the regression suite

Of course, when adding new features, one should write tests that cover these features. In total, I have added four new tests to the regression suite covering various aspects of SDF INTERCONNECT.

OpenLane Example Designs

But do we have any real world examples showcasing the SDF INTERCONNECT implementation? For example, with a manufacturable PDK, like SKY130? Yes we do! I have prepared several designs for simulation in the interconnect-tests repository.

I used OpenLane to harden three different designs:

  • ALU (combinatorial)
  • Counter (8-bit counter with load)
  • RISC-V CPU (picorv32)

This gives us the gate-level Verilog and the corresponding SDF file. The GL Verilog is simulated with iopath and interconnection delays enabled. A Python script reads the resulting waveforms and compares the interconnect signal transition delays with the delays specified in the SDF file. All three designs have a 100% pass rate. That said, there are a few minor issues remaining, but they do not hinder or affect the simulation.

Macro of PicoRV32

Simulation summary for interconnection delays

Therefore the third and last task has been completed:

  • ✅ Example of a SDF back-annotated timing simulation using the SKY130 PDK

But I did not stop there.

An Excursion Into Timing Checks

Because there was still some time left and the project had not concluded yet, I decided to take a look into implementing timing checks in Icarus Verilog. You can read about it in last weeks blog post: GSoC23 — Workweek 15 . I managed to implement most of the $width timing check. One important step is still missing: the automatic insertion of .tchk_width records into the vvp source file. Hopefully I get this done soon!

  • ✅ Starting with the implementation of the first timing check ($width)

Challenges and Learnings

The biggest challenge was getting a foothold in the code base of Icarus Verilog. There are just so many different components to it that one first must really understand how they interact with each other before starting to think about adding a new feature. It turned out my documentation rework and cleanup has helped me a lot to understand Icarus Verilog.

I also learned that the approach you choose must not always be the best one, and that sometimes it's better to take a step back and start new.

Finally, I improved my documentation skills by not only writing this final project report, but various issue reports, pull requests, and a total of 15 blog posts. Yes, I've managed to publish one blog post every week about my current work - and they're not even half bad!

Here is a list of all my GSoC work week reports:

Future Plans

In the short term, the amount of work I can invest into open source is reduced as university starts again.

But I definitely plan to continue contributions to Icarus Verilog. The next steps are to implement timing checks and to properly delay the signals for $recrem and $setuphold.

I personally want to continue contributing to open source. It just makes such a difference knowing that the work you've done might by helpful to others - and that others, in turn, might contribute their work back.

Final Words - Thank You

That's it from me for GSoC23. I can definitely recommend GSoC if you already have a specific open source project in mind as a way to improve your skills and to bond with the open source community.

It was challenging and there were times when I did not exactly know how to continue, but despite that, or maybe because of that, I learned a lot that I would not want to miss.

I would like to thank my mentors who helped me along this journey, each in their own way.

  • Tim Edwards
  • Mohamed Shalan
  • Cary R

It's a great thing to have multiple mentors. It has given me more perspectives from which to look.

I would also like to thank the FOSSi Foundation for acting as the umbrella organization.

Finally, I would like to thank my family for being there and supporting me whenever I needed it.