Session 6 > Synthesis & Physical Design

Class Review

Synthesis > Yosys

Synthesis converts RTL code into a netlist of logic gates

Yosys is a synthesis tool, used after a design is written in Verilog.

Yosys can generate a report with warnings, latches, wire count, number of cells, etc.

Use the report results to debug design or determine if it can fit onto a Tiny Tapeout tile.

Tiny Tapeout Capacity…less than 500 cells can fit comfortably in 1 tile, max 1000 cells (put pushing it).

Gate Count Estimation

Standard Cell

Standard Cell = provides pre-designed, pre-characterized logic gates (with parameters that a foundry has already verified)

Place & Route

Place & Route takes a synthesized netlist and creates a physical layout

OpenRoad open-source software is used to change a netlist to a physical layout diagram

OpenLane is a wrapper around OpenRoad.

Timing Analysis

GDS

GDS is the final output for manufacturing

Research

Yosys = open-source hardware synthesis tool used in digital chip design, converts Verilog code (optimizing the logic) into a gate-level representation (a Netlist…components and their connections) that can be implemented on an FPGA or Fabricated as an ASIC. (ChatGPT)

From…
verilog > y = a & b

To…
AND gate input1 > a
input2 > b
output > y

Or if a State Machine, to…
- Flip-flops
- Logic Gates
- Multiplexers

Yosys does not simulate a circuit…it translates into hardware.

Synthesis is the 3rd step in the chip design flow:
1. Write RTL code > Verilog
2. Simulate > verify behavior
3. Synthesize > convert into logic gates
4. Place & Route > change to physical layout (graphic shapes)
5. Fabricate the chip

Tiny Tapeout Flow

Verilog > Yosys > Gate Netlist > OpenLane > GDS (Chip Layout)

Assignment Work

[x] Synthesize your design - review gate count and check for unintended latches
[x] Run place and route flow
[x] Analyze timing reports - Identify and fix any violations
[x] Generate GDS and review layout in KLayout

I have done a fair amount of work for this assignment as I worked on my Final Project idea, mostly writing Verilog code. As I was writing documentation and writing Verilog code in VScode, I was loathe to rewrite everything again inside the docker (since Cut & Paste is not possible).

Reviewing the process and software I would need to go from Verilog to GDS, it occurred to me that I could just install the needed software I needed locally on my PC…so that I could complete my assignments and Final Project easier (outside of the docker). At least I hope so.

Here is what I now understand about the Concept-to-ASIC process and the software needed to go from design to fabrication:

From design to ASIC fabrication:
1. Conceptualize the Functionality of a Small Chip Design
- Answer > What do I want the chip to do?
- ex: “Blink and LED when a button is pushed”
- Make a functionality flow diagram

1. Write Verilog RTL Code

   • Describe the conceptual functionality as data-level (RTL) code descriptions
   • Use Icarus-Verilog

2. Simulate the design

   • Test the RTL code in simulation to ensure the functionality works as expected
   • Use Icarus-Verilog

3. View simulation waveforms

   • Review waveforms generated by the simulation to confirm correct functionality
   • Use GTKwave

4. Synthesize RTL into Gate Level representation

   • Convert RTL code into a gate-level description of the hardware circuit
   • Use Yosys

5. Place & Route connection

   • Define physical connections between gates and output GDS file
   • Use OpenRoad

6. Inspect Layout

   • Review chip design physical layout for errors
   • Use KLayout

7. Send GDS to Chip Foundry for Fabrication

   • Wait 6 months
   • Pay > USD200

So 8-steps and 5 software.

Icarus-Verilog, GTKwave, and KLayout installed easy enough as Windows executables. One, two, three…done.

For other software, a Linux environment was recommended, so a Windows Subsystem Linux (WSL) virtual Linux environment was installed into my PC. I chose to go with the Ubuntu 24.04 distribution. A few commands in the PowerShell terminal later, Ubuntu was installed and the installation of Yosys went easily after that. Four down, only one to go.

Installing OpenRoad proved to be a huge challenge. I literally spent a full day trying to debug the process, trying one thing after another. And thanks to ChatGPT’s advice, I muddled my way through and learned a ton getting error messages explained to me for 24 hours. It turns out that OpenRoad doesn’t run well on the latest Ubuntu distro 24.04. But it does fine in the Ubuntu 22.04 environment. So I downgraded to Ubuntu 24.04 and the OpenRoad install succeeded with little difficulty (the installation did take nearly 1 hour!).

Installing OpenRoad

Testing OpenRoad
The install took forever! Even after I got it installed in Ubuntu 22.04, there were missing dependencies that needed installing. Once all fixed, impossible without ChatGPT guidance, I did a test run (as it suggested). And generated a successful result.

ChatGPT gave the following assurances:

Running KLayout Test:

With the successful of imaging of the test in KLayout, local tools on my PC is confirmed to be able to produce results for the Concept-to-ASIC workflow.

1. RTL
2. Yosys
3. OpenRoad
4. GDS
5. KLayout

Are all operational.

Synthesis, Place & Route, and GDS Generation

So FINALLY, let’s do homework. ChatGPT was consulted frequently to answer questions and explain errors in the completion of this homework exercise.

Writing Verilog Code
ChatGPT recommended that I use a simple text editor called Nano to write my Verilog code in the WSL environment.

I cobbled together a simple Tone Generator project, where a square wave it generated at fixed frequency. The code has:

• Clock INPUT
• Reset INPUT
• Audio_out OUTPUT Register
• 16-bit Counter
• Always block that checks for either clock or reset rising edge
• The counter counts up to 25000 then outputs a tone…and resets

module tone_generator(
    input clk,
    input reset,
    output reg audio_out
);

reg [15:0] counter;

always @(posedge clk or posedge reset) begin
    if(reset) begin
        counter <= 0;
        audio_out <= 0;
    end else begin
        if(counter == 16'd24999) begin
            counter <= 0;
            audio_out <= ~audio_out;
        end else begin
            counter <= counter + 1;
        end
    end
end

endmodule

Yosys
A single command was all it took to perform Yosys simulation on the Tone_Generator code file.

A few minutes later, a Netlist analysis was completed.


I was surprised to discover that the simple code resulted in 88 Standard Logic Cells, in addition to wires and ports. Thankfully, zero problems were reported.

This was followed by a simulation run using Testbench code on the Tone Generator code.

`timescale 1ns/1ps

module testbench;

    reg clk;
    reg reset;
    wire audio_out;

    tone_generator uut (
        .clk(clk),
        .reset(reset),
        .audio_out(audio_out)
    );

    initial begin
        clk = 0;
        forever #10 clk = ~clk;   // 20 ns period
    end

    initial begin
        $dumpfile("dump.vcd");
        $dumpvars(0, testbench);

        reset = 1;
        #50;
        reset = 0;

        #2000000;   // run long enough to see output toggle
        $finish;
    end

endmodule

The Testbench code had the following features:

• timescale of 1 nanosecond and resolution of 1 picosecond

  forever #10 clk = ~clk

• the testbench clock generates a rising and falling edge every 10 nanoseconds, so a period of 20 nanoseconds or a 50MHz clock
• generates clk and reset INPUT signals
• outputs audio_out OUTPUT signal
• will generate a waveform file called ‘dump.vcd’

Again, a simple line of code initiated the simulation. Starting with compilation by Icarus Verilog.

iverilog -o sim tone_generator.v testbench.v

A sim file is created and the simulation was executed with this Verilog Virtual Processor (vvp) command…

vvp sim
The testbench code drives input into the tone generator program, and creates a waveform file called dump.vcd.

GTKwave
To see the waveform, the following command was run on the dump.vcd file…

gtkwave dump.vcd And this resulted…no audio out! Debugging revealed that the issue was that the counter trigger point specified in the tone generator code (25000) was too long. The testbench code ended before the first trigger point was even activated.

So I adjusted the code to have a much more frequent counter trigger of 10.

if(counter == 16’d9) begin

And the square waveform is apparent on the rerun of gtkwave.

KLayout

Entering the following at the command line…

klayout results/sky130hd/tone_generator/base/6_final.gds
…launched KLayout and generated the board image.

To try to understand it better, I toggled individual layer view. Layers ending with ‘20’ showed the following shapes…probably corresponding to metal, poly and diffusion layers. Still need to decipher, but they look pretty!!

KLayout Cell Name Shortcuts: - dfxtp = flip-flop
- and2 = AND gate
- xnor2 = comparator logic
- clkbuf = clock tree buffer

KLayout Layer Name Convention:
- Two numbers separated by a slash
- The first number is the Layer Number
- The second number is the Data Type

Enable Layer Names will replace numbers with names like met1, via1, li1, poly, diff

KLayout Layer Color Coding:
- Diffusion = Green - Poly = Red - Metal1 = Blue

Is it just me, or does this look like the structure from Donkey Kong?

…with wires shown

I am still struggling to find my way around the KLayout software interface, but I need to drop further investigations until later. Final Project work beckons!!

Reports

The simulation generated a ton of output in the terminal. ChatGPT guided me in reviewing key reports: Synthesis Statistics, Timing, and Routing Errors.

Synthesis Statistics

cat reports/sky130hd/tone_generator/base/synth_stat.txt

• Number of Cells: 72 (not so many)
• Number of Flip-Flops 17 (1 audio_out, 16 counter)
• Combinational Logic Cells: ~55 cells
• Area: 779.498 square microns
• Sequential (element) Percentage: ~55%

Timing

cat reports/sky130hd/tone_generator/base/6_finish.rpt

The report output was extensive. ChatGPT guides that I should look for ‘slack’ in the report, with ‘slack(MET)’ meaning a good result and ‘slack(violated)’ meaning bad. There appeared to be several timing tests done and all reported ‘slack(MET)’.

• Critical Path Delay: 1.9016 ns (logic switching speed)
• Clock Constraint: 20 ns
• Finish Critical Path Slack: 18.0984 ns (plenty of timing headroom)
  

Conclusion: the logic “is simple and fast”
- Power Consumption: 0.0000603 W (60 microwatts)

• Sequential Power Consumption %: 57%
• Clock Power Consumption %: 41%
• Logic POwer Consumption %: 1.6%

• Worst Timing Path: counter > logic > audio_out
  

• Timing Violations: none

• Clock Skew: 0.01 ns (clean clock tree)

Calculating Maximum Frequency: fmax = 1/minimum clock period
fmax = 1/1.9ns = 525.87MHz (chip’s max speed)

Reflection

With the completion of this assignment, I believe that I have successfully tested the full Concept-to-ASIC pipeline, and have an operational baseline to start working on my Final Project. I am pretty confident now that the procedure works in USL Ubuntu 22.04 running locally on my laptop:

1. Nano > Write/Edit Verilog RTL code
2. Icarus Verilog > compile Verilog code
3. Yosys > Synthesize and test design
4. GTKwave > View waveforms
5. OpenRoad > Simulate the circuit
6. OpenRoad > Place and Route with sky130hd specifications
7. OpenRoad > Verification testing
8. OpenRoad > Output GDS file for fabrication