Skip to content

Final

First try digital curcuit design analog way

System spec

Traffic Light Controller Waveform

FSM

Traffic Light Controller Waveform

Boolean eq

Traffic Light Controller Waveform

Now try digital curcuit design digital way

From Spec to Verilog (2005)

module traffic_light_controller (
    input  wire clk,
    input  wire reset,
    input  wire ta,      // Sensor for street A
    input  wire tb,      // Sensor for street B
    output reg [1:0] la, // 00: Green, 01: Yellow, 10: Red
    output reg [1:0] lb  // 00: Green, 01: Yellow, 10: Red
);

        // State Encoding (Binary)
        parameter S0 = 2'b00; // Street A Green
        parameter S1 = 2'b01; // Street A Yellow
        parameter S2 = 2'b10; // Street B Green
        parameter S3 = 2'b11; // Street B Yellow

        // Light Color Encoding
        parameter GREEN  = 2'b00;
        parameter YELLOW = 2'b01;
        parameter RED    = 2'b10;

        reg [1:0] current_state;
        reg [1:0] next_state;

        // State Register (Sequential Logic)
        always @(posedge clk or posedge reset) begin
                if (reset)
                        current_state <= S0;
                else
                        current_state <= next_state;
        end

        // Next State Logic (Combinational Logic)
        always @(*) begin
                case (current_state)
                        S0: begin
                                if (ta) next_state = S0;
                                else    next_state = S1;
                        end
                        S1: next_state = S2;
                        S2: begin
                                if (tb) next_state = S2;
                                else    next_state = S3;
                        end
                        S3: next_state = S0;
                        default: next_state = S0;
                endcase
        end

        // Output Logic (Moore Machine: depends only on current_state)
        always @(*) begin
                case (current_state)
                        S0: begin la = GREEN;  lb = RED;    end
                        S1: begin la = YELLOW; lb = RED;    end
                        S2: begin la = RED;    lb = GREEN;  end
                        S3: begin la = RED;    lb = YELLOW; end
                        default: begin la = RED; lb = RED;  end
                endcase
        end

endmodule

Running Testbenches

  • make compiles code and runs simulation to generate .vcd file
  • make view opens GTKWave with results
  • make sim cleans, recompiles, runs simulation, and opens waveforms in one step
  • make clean removes compiled output and waveform files

Waveform Results

Traffic Light Controller Waveform Traffic Light Controller Waveform

Observations from Waveform

  • Reset Phase: Reset signal is high initially; la is 00 (Green) and lb is 10 (Red)
  • Transition Phase: Once ta drops, la transitions from 00 (Green) → 01 (Yellow) → 10 (Red), while lb transitions from 10 (Red) → 00 (Green).
  • Timing: State changes seems aligned to rising edges.

Running Synthesis

make synth

synth_netlist.v file will be created. That is yor “gate-Level” version of the FSM

verilog code describes the behavior spec(Math), the netlist describes the physical connections

Traffic Light Controller Waveform

Synthesize for Sky130

When you synthesize for Sky130, Yosys won’t just use an $AND generic logc; it will use something like sky130_fd_sc_hd__and2_1, includes information about physical size, drive strength, and transistor layout.

make synth_sky

Traffic Light Controller Waveform

Schematic

When you have a netlist with real-world cells like Sky130, the diagram generator (Graphviz) creates this, not sure how usefull it’s ? Traffic Light Controller Waveform

Gate-level simulation

Sky130 Verilog models contain actual timing information. Signals now have to physically travel through transistors, which takes a tiny amount of time (picoseconds), more “realistic” then usual simulation ``` make gate_sim_sky````

Traffic Light Controller Waveform

Didn’t see difference from the usual one, so idk – this need to be checked again

Physical design

make openroad-gui

Got some error on pdngen(Power Distribution Network (PDN) still fails with “No shapes” so i have to skip that not sure what would be the consequenses of that

It’s still in the openroad.tcl file, simplified

Traffic Light Controller Waveform Traffic Light Controller Waveform

Try unchecking met1 or li1 to see how the connections disappear

Traffic Light Controller Waveform

Generate GDS

make gds

Traffic Light Controller Waveform

To create a GDS, Magic needs the GDS library of the standard cells, so you need to tell Magic to look into the actual GDS library of the PDK – Fix/s are in the make files uses generate_gds.tcl

view_gds:
    klayout traffic_light.gds

Traffic Light Controller Waveform

This was from RTL to GDSII Flow

DRC (Design Rule Check)

make drc

checks if any wires are too close, if the transistors are sized correctly, and if the layout follows the “physics” of the Sky130 factory.

Magic has real-time DRC engine.

Traffic Light Controller Waveform

LVS (Layout vs. Schematic)

DRC only checks if the wires are “legal” (not too close). LVS checks if the wires are correct.

To run LVS, we are going to compare two things:

The Source: original Verilog netlist (synth_netlist.v).

The Layout: The physical connections extracted from GDS file (traffic_light.gds).

The tool Netgen will look at both and tell us if they are electrically identical.

it’s in extract_for_lvs.tcl which creates lvs_report.txt

make lvs

Traffic Light Controller Waveform

Despite the pin error, it has this “Device classes traffic_light_controller and traffic_light_controller are equivalent.”

Packaging & Board Design

TODO

Downlaods

Download RTL source

Download Test

Download Makefile

CC

Used examples from the book

  • https://www.amazon.com/Digital-Design-Computer-Architecture-ARM/dp/0128000562