D6 From RTL Code to Tapeout-Ready Layout

You have already experienced the complete minirv processor design flow in the E stage. Now, let's take a closer look at the individual steps involved:

Functional Verification - Checking through RTL simulation whether the circuit described by the RTL code behaves as expected
Circuit Evaluation - Converting the logic elements of the RTL code into a netlist of physical standard cells using a synthesizer
Physical Design - Converting the netlist of standard cells into a tapeout-ready layout

RTL Simulation - Functional Verification

You have already used Verilator for RTL simulation, but you may not yet understand how RTL simulation works under the hood.

In fact, the essence of RTL simulation is to use a software program to mimic the behavior of a hardware circuit. Therefore, to implement RTL simulation, we need to consider how to use a C program state machine to implement the state machine of a digital circuit. To do this, let us first review the C program from the perspective of a state machine:

	C Program	Digital Circuit
State	Variables	Sequential Logic Circuit
Stimulus Event	Executing Statements	Processing Combinational Logic
State Transition Rule	Semantics of Statements	Combinational Logic

To implement the state machine of a digital circuit using a C program state machine, we need to develop a C program with the following functionalities:

Represent the circuit state with C program state, that is, implement the sequential logic circuit using variables in the C program.
Implement the state transition rules of the digital circuit using the state transition rules of the C program, that is, implement the logic of the combinational logic circuit using C language statements.

Review the Verilog code for a running light module:

module light(
  input clk,
  input rst,
  output reg [15:0] led
);
  reg [31:0] count;
  always @(posedge clk) begin
    if (rst) begin led <= 1; count <= 0; end
    else begin
      if (count == 0) led <= {led[14:0], led[15]};
      count <= (count >= 5000000 ? 32'b0 : count + 1);
    end
  end
endmodule

According to the circuit described by the above Verilog code, we can design a C program to perform an RTL-level simulation of this circuit:

#include <stdio.h>
#include <stdint.h>

#define _CONCAT(x, y) x ## y
#define CONCAT(x, y)  _CONCAT(x, y)
#define BITMASK(bits) ((1ull << (bits)) - 1)
// similar to x[hi:lo] in verilog
#define BITS(x, hi, lo) (((x) >> (lo)) & BITMASK((hi) - (lo) + 1))
#define DEF_WIRE(name, w) uint64_t name : w
#define DEF_REG(name, w)  uint64_t name : w; \
                          uint64_t CONCAT(name, _next) : w; \
                          uint64_t CONCAT(name, _update) : 1
#define EVAL(c, name, val) do { \
                             c->CONCAT(name, _next) = (val); \
                             c->CONCAT(name, _update) = 1; \
                           } while (0)
#define UPDATE(c, name)    do { \
                             if (c->CONCAT(name, _update)) { \
                               c->name = c->CONCAT(name, _next); \
                             } \
                           } while (0)

typedef struct {
  DEF_WIRE(clk, 1);
  DEF_WIRE(rst, 1);
  DEF_REG (led, 16);
  DEF_REG (count, 32);
} Circuit;
static Circuit circuit;

static void cycle(Circuit *c) {
  c->led_update = 0;
  c->count_update = 0;
  if (c->rst) {
    EVAL(c, led, 1);
    EVAL(c, count, 0);
  } else {
    if (c->count == 0) {
      EVAL(c, led, (BITS(c->led, 14, 0) << 1) | BITS(c->led, 15, 15));
    }
    EVAL(c, count, c->count >= 5000000 ? 0 : c->count + 1);
  }
  UPDATE(c, led);
  UPDATE(c, count);
}

static void reset(Circuit *c) {
  c->rst = 1;
  cycle(c);
  c->rst = 0;
}

static void display(Circuit *c) {
  static uint16_t last_led = 0;
  if (last_led != c->led) { // only update display when c->led changes
    for (int i = 0; i < 16; i ++) {
      putchar(BITS(c->led, i, i) ? 'o' : '.');
    }
    putchar('\r');
    fflush(stdout);
    last_led = c->led;
  }
}

int main() {
  reset(&circuit);
  while (1) {
    cycle(&circuit);
    display(&circuit);
  }
  return 0;
}

The program implements the sequential logic circuit through the structure variable circuit, which includes led and count. Although clk and rst do not belong to the sequential logic circuit, they are part of the circuit state as inputs of the circuit, so they also appear in the structure. In addition, the program implements the logic of the combinational logic circuit through C language statements. As you can see, the content of the above cycle() function is basically a direct translation of the corresponding Verilog code, except for the introduction of some intermediate variables with the suffix next and update flags with the suffix update. These intermediate variables are introduced to implement the semantics of Verilog non-blocking assignments, that is, the update of the corresponding signals needs to wait until the end of the cycle. Therefore, during the simulation process, the calculation results of the combinational logic need to be temporarily stored in these intermediate variables and the update flags set; only at the end of a cycle, the calculation results are actually written into the variables related to the sequential logic elements according to the update flags.

The while loop in the main() function reveals the main process of RTL simulation: by continuously executing the cycle() function, it realizes the function of "calculating and updating the new state based on inputs and the current state". This function is actually the essence of how digital circuits work. However, before entering the while loop, the circuit also needs to be reset through the reset() function. In addition, although the display() function does not belong to the circuit itself, in order to present the functionality of the circuit, the display() function outputs the corresponding character according to the state of each bit of the led signal, thereby displaying the running light effect on the terminal.

The above simulation program is written manually. But if developers have to manually write a corresponding simulation program for each circuit design in order to carry out functional verification, this would bring a lot of trouble to developers. For this reason, developers generally use an RTL simulator software to automatically convert RTL code into a C program used to simulate the circuit behavior. This C program is the circuit simulation program corresponding to the RTL code.

The Verilator you used earlier is an example of such an RTL simulator.

The Simulation Behavior and Coding Style of Verilog

Similar to the C language standard, the semantics of the Verilog language during simulation are defined by the Verilog Standard Manualopen in new window. Chapter 11 of the manual reveals the essence of the Verilog language. This chapter is not long, only 5 pages, but it contains a huge amount of information (yzh thinks this part is so important that it should be moved earlier to Chapter 3 of the manual). However, these essences are not mentioned in traditional textbooks and most Verilog materials, so the vast majority of Verilog developers, even some practitioners with rich Verilog experience, do not know the existence of these semantics, and thus cannot precisely understand the differences between Verilog in the two usage scenarios of simulation and synthesis.

The introduction of the Verilog Standard Manual contains the following:

It was designed ... for a variety of design tools, including verification
simulation, timing analysis, test analysis, and synthesis.

This shows that Verilog was proposed for a series of circuit design tools. Therefore, this series of tools can all be regarded as concrete implementations of the Verilog standard, including simulation tools, timing analysis tools, test analysis tools, synthesis tools, and so on. However, the frequency with which simulation appears in the Verilog Standard Manual (356 times) is much higher than that of synthesis (4 times), so the Verilog Standard Manual is still more oriented towards simulation tools.

I can write Verilog, isn't that enough? Why do I need to know these things?

In fact, many Verilog developers really do not know the essence of Verilog, but they can still design circuits whose behavior is mostly as expected by following certain Verilog coding suggestions. However, they do not know the essence behind these coding suggestions, nor can they judge whether a coding suggestion is correct. When they encounter unexpected situations during simulation, they have no ability to analyze the cause of the problem, and can only make blind changes randomly. If they cannot fix it by making changes, they may even complain in their mind that the simulator has a bug...

As a small test, here are several Verilog coding suggestions or descriptions, but some of them are incorrect. Please try to find them out:

Using #0 can force an assignment to be delayed until the end of the current simulation time.
In the same begin-end statement block, performing multiple non-blocking assignments to the same variable results in undefined behavior.
When describing combinational logic elements with an always block, non-blocking assignments cannot be used.
A variable cannot be assigned in multiple always blocks.
It is not recommended to use the $display system task, because sometimes it cannot correctly output the value of a variable.
$display cannot output the result of a non-blocking assignment statement.

If you plan to use the Verilog language in subsequent development and cannot judge whether the above descriptions are correct, we strongly recommend that you carefully understand this part of the content.

Execution of Verilog Code

We know that the execution of C language refers to modifying the state of objects through a certain evaluation order that conforms to the standard specification. Then in Verilog, what does "execution" mean? To get a clear answer, we need to consult the Verilog Standard Manual. Section 11.1 of the manual defines what "executing Verilog code" means:

The elements that make up the Verilog HDL can be used to describe the behavior, at
varying levels of abstraction, of electronic hardware. An HDL has to be a parallel
programming language. The execution of certain language constructs is defined by
parallel execution of blocks or processes. It is important to understand what
execution order is guaranteed to the user and what execution order is indeterminate.

Although the Verilog HDL is used for more than simulation, the semantics of the
language are defined for simulation, and everything else is abstracted from this
base definition.

That is to say, the Verilog language is used to describe the behavior of hardware at various levels of abstraction (including system level, behavioral level, RTL level, gate level, and transistor level). HDL is a parallel programming language, and the execution of some language components is defined as the parallel execution of code blocks or processes. It is crucial for Verilog users to understand what execution order is guaranteed by the standard manual and what execution order is indeterminate. Although the usage scenarios of Verilog are not limited to simulation, the semantics of Verilog are defined for simulation, and the semantics of other scenarios are abstracted based on this basic definition.

Have you felt that your understanding of Verilog has been subverted?

The essence of Verilog is actually a parallel programming language! Moreover, the language standard of Verilog is defined for simulation, not for RTL design! Furthermore, the semantics of Verilog are indeterminate in some scenarios! This is somewhat similar to the unspecified behavior or undefined behavior in C language: understand what coding styles will introduce indeterminacy, and then avoid these coding styles during the use of Verilog, thereby ensuring that the behavior of the described object is deterministic.

This means that the semantics of some Verilog code may not conform to your intuition, or there may be a difference between the simulation behavior and the synthesis behavior. If you have used Verilog before and have had experiences like "the simulation passed but it did not run correctly on the FPGA", after ruling out FPGA-related detailed issues, if you still do not understand the reason, it is very likely because you have not understood the above essence of the Verilog language. Now is the time to further deepen your understanding of it!

Event-Based Simulation

Section 11.2 of the Verilog Standard Manual introduces the simulation process:

The Verilog HDL is defined in terms of a discrete event execution model.

The Verilog language is defined based on a discrete event execution model. We pick some key content to continue the explanation:

Processes are objects that can be evaluated, that may have state, and that can
respond to changes on their inputs to produce outputs. Processes include primitives,
modules, initial and always procedural blocks, continuous assignments, asynchronous
tasks, and procedural assignment statements.

In Verilog, "processes" are objects that can be evaluated. These objects have their own states, and when their inputs change, they can respond to these changes and produce outputs. Processes include primitives, modules, initial and always procedural blocks, continuous assignments, asynchronous tasks, and procedural assignment statements.

Every change in value of a net or variable in the circuit being simulated, as well
as the named event, is considered an update event.

Processes are sensitive to update events. When an update event is executed, all the
processes that are sensitive to that event are evaluated in an arbitrary order. The
evaluation of a process is also an event, known as an evaluation event.

In the circuit being simulated, a change in the value of a net or variable, as well as a named event, is regarded as an "update event". Processes are sensitive to update events. After an update event is executed, all processes sensitive to that event will be evaluated, and the evaluation order is arbitrary. The evaluation of a process is also an event, called an "evaluation event".

Events can occur at different times. In order to keep track of the events and to
make sure they are processed in the correct order, the events are kept on an event
queue, ordered by simulation time. Putting an event on the queue is called
scheduling an event.

Events occur at different simulation times. In order to ensure that events are processed in the correct order, they need to be stored in an event queue ordered by simulation time. Putting an event into the queue is called "scheduling of the event".

As you can see, the semantics of Verilog language components are all associated with events. The simulation process is the process of processing these events in some correct order. During the processing of events, the states of the objects in the circuit will change. We expect this change to conform to the expected behavior of the circuit, thereby realizing the simulation of the circuit's behavior.

Hierarchical Event Queue

According to the Verilog Standard Manual, the event queue logically contains the following 5 regions, each used to handle the corresponding type of events:

Active event region, denoted as , which stores events that occur at the current simulation time and can be processed.
Inactive event region, denoted as , which stores events that occur at the current simulation time but cannot be processed immediately; these events can only be processed when is empty.
Nonblocking assign update event region, denoted as , which stores events that have completed evaluation at previous simulation times but need to be assigned at the end of the current simulation time; these events can only be processed when both and are empty.
Monitor event region, denoted as , which stores events related to monitoring operations; these events can only be processed when , , and are all empty.
Future event region, denoted as , which stores events to be processed at future simulation times.

An event is added to different regions according to its type, and transferred to according to certain rules; after being processed, it is removed from the event queue. Some rules for generating events are as follows:

Explicit zero delay (#0) can suspend the corresponding process and will generate an event.
A nonblocking assignment will generate an event.
The system tasks $monitor and $strobe will generate an event at each simulation time.
The evaluation of PLI processes will generate an event.

According to the above processing order of different events, the Verilog Standard Manual provides a reference implementation of the event processing engine, which is the core loop of the Verilog simulator:

while (there are events) {
  if (no active events) {
    if (there are inactive events) {
      activate all inactive events;
    } else if (there are nonblocking assign update events) {
      activate all nonblocking assign update events;
    } else if (there are monitor events) {
      activate all monitor events;
    } else {
      advance T to the next event time;
      activate all inactive events for time T;
    }
  }
  E = any active event;
  if (E is an update event) {
    update the modified object;
    add evaluation events for sensitive processes to event queue;
  } else { /* shall be an evaluation event */
    evaluate the process;
    add update events to the event queue;
  }
}

The event processing engine will repeatedly perform the following operations:

If there are events in , take out an event E
- If E is an update event, then
  - Update the corresponding object
  - Add the evaluation of the processes sensitive to this event to the event queue as evaluation events
- Otherwise, E is an evaluation event, then
  - Evaluate the process
  - Add the assignment behavior to the event queue as an update event
Otherwise (i.e., is empty)
- If is not empty, transfer all the events in to
- Otherwise, if is not empty, transfer all the events in to
- Otherwise, if is not empty, transfer all the events in to
- Otherwise
  - Advance the simulation time by one unit
  - Transfer all the events in that belong to the current simulation time to or according to their types

Verilog Code != C Code

For teachers of digital circuit courses, the most troublesome thing is that when students learn Verilog, they easily write Verilog code according to the programming thinking of C language. Even though the teacher has repeatedly emphasized that "Verilog cannot be written as C language", most students still cannot deeply understand the meaning of this sentence: if it cannot be written as C language, then what exactly is Verilog?

The reason we introduce the content of the Verilog Standard Manual here is to present the answer to this question. The above event processing loop has directly presented the difference between Verilog code and C code: take i = i + 1 as an example. In a C program, under the action of the compiler, this line of code is finally compiled into an instruction similar to addi a0, a0, 1, which is directly executed on the processor; while in Verilog, this line of code will be converted into an evaluation event and an update event, which complete the addition operation and the assignment operation under the processing of the event processing engine, and generate new events sensitive to them.

In fact, the Verilog code you write will eventually be converted into events one by one according to the conventions of the standard manual. The simulator processes these events in some order that conforms to the conventions of the standard manual, and reflects the overall behavior of the hardware circuit through the results of the processing, thereby realizing the modeling of the hardware circuit.

Event Scheduling for Assignment Operations

According to Section 11.6 of the Verilog Standard Manual, assignment operations are converted into behaviorally equivalent processes, thereby generating corresponding events to be processed by the simulator. We select some common assignment operations for explanation. For simplicity, we first consider the case where no delay information (#) is specified.

Continuous assignment (i.e., assign statement) - Corresponds to a process sensitive to all source operands of the expression. When the value of the expression changes, an update event will be generated and added to . In particular, the continuous assignment process generates an evaluation event at time 0, used to realize constant propagation.
Blocking assignment within a process - First calculate the value of the right-hand side of the assignment expression using the current value of the object, then immediately calculate the target object on the left-hand side of the assignment expression, update it, and generate the events caused by this update. The execution process can continue to execute the next statement in sequence, or process other active events.
Non-blocking assignment within a process - First calculate the value of the right-hand side of the assignment expression and the target object on the left-hand side using the current values of the objects, and generate an event for the current simulation time.

A New Understanding of Blocking and Non-blocking Assignments

For teachers of digital circuit courses, the second most troublesome thing is that students find it hard to understand the difference between blocking assignments and non-blocking assignments. The C language has only one kind of assignment, but Verilog has several kinds of assignments. To deeply understand the difference between different assignment methods, we still have to return to the essence of Verilog, that is, the event model.

Contrary to everyone's intuition, in the event model of Verilog, the specific operation of an assignment expression needs to be considered in terms of two sub-operations: first is the evaluation operation, used to complete the evaluation process of the right-hand side of the assignment expression; then is the update operation, used to write the evaluation result into the object indicated by the left-hand side of the assignment expression.

According to the event scheduling behavior mentioned above, the biggest difference between blocking assignments and non-blocking assignments is that the two handle the update operation differently. Specifically, the update operation of a blocking assignment is performed together immediately after the evaluation operation, without generating a new update event; while for a non-blocking assignment, the evaluation operation and the update operation are separated. After completing the evaluation operation, an update event belonging to is generated, and this update event can only be processed when both and are empty. It is precisely this difference that makes the timing at which the two carry out the specific assignment operation different, further making the set of events that can see the assignment result different, thereby affecting the behavior of these events, and ultimately affecting the overall behavior of the circuit.

Use the Event Model to Analyze the Behavior of Verilog Code

Consider the following code, assuming that at time t there are a = 1, b = 2, c = 3, d = 4, e = 5. Try to use the event model to analyze what the values of the variables are at time t+1.

always @(posedge clk) begin
  b  = a;
  c <= b;
  d  = c;
  e <= d;
  a  = e;
end

Port connections - For the input port connection .a(expr), it is treated as the continuous assignment statement assign a = expr;; for the output port connection .b(net), it is treated as the continuous assignment statement assign net = b;.
Functions and tasks - Parameters are passed by value when called. When returning, the behavior of "replacing the call site with the return value" is handled as a blocking assignment.

The Verilog manual also defines how to convert more cases into events for processing, including specifying delay information, using procedural continuous assignment statements, handling transistor-level behavior, and so on. When you need to understand them, you can consult the relevant content in the manual.

Event Processing Order

In fact, the order of event processing is not 100% deterministic. According to the definition of the Verilog Standard Manual, the indeterminacy mainly comes from two sources:

When there are multiple active events in the event queue, the processing order is arbitrary.
In behavioral modules, statements without time control (i.e., # expressions and @ expressions) do not have to be processed as a whole event. When evaluating a statement in a behavioral module, the simulator can suspend the execution of this statement at any time, and treat the remaining execution operations as an active event in the event queue. This allows different processes to be interleaved in execution, but the order of interleaving is indeterminate and not under the user's control.

Why does Verilog need to introduce these indeterminacies? To answer this question, we need to review the working method of hardware circuits. In fact, the behavior of hardware circuits is itself parallel: multiple components naturally work in parallel.

From the perspective of consistency between the circuit behavior model and the real circuit, there is no reason to specify the working order among these components. If these orders are forcibly specified, the modeling result will not be able to comprehensively reflect the working situation of the real circuit. In particular, if there is a problem in the real circuit but it cannot be reflected through modeling and repaired in time, the modeling loses its meaning.
From the perspective of the software essence of the simulator, the simulator can only process different events serially. The above indeterminacy defined by the Verilog standard is actually a kind of "relaxation" of the event processing order: if there is no dependency between two events, there is no need to require them to be processed in a certain order. Furthermore, the simulator can even use some parallel optimization techniques to process these events without dependencies, thereby better simulating the parallelism among circuit components.

To comprehensively understand the behavior of Verilog code, we also need to consider the determinism of the event processing order. For convenience of expression, we introduce an order relationship, denoted as , where means that event is processed before event . The event processing engine mentioned above actually implies some order requirements:

Order Rule 1 - If is generated during the processing of , then . This is because, to process , the processing of must be completed first.
Order Rule 2 - If at a certain moment during the simulation, , , and , then . This is because the event processing engine processes all the events in first, and only then processes the events in .

In addition to these implicit orders, the Verilog Standard Manual explicitly defines the following two order rules:

Order Rule 3 - The statements in a begin-end statement block need to be executed in statement order. That is, for two statements and in the same begin-end statement block, if , then is executed before .
Order Rule 4 - Non-blocking assignment operations need to be carried out in the execution order of the statements. That is, if , and the evaluation operations of the corresponding assignment expressions are and respectively, with , then .

For example, the Verilog Standard Manual has the following example:

initial begin
  a <= 0; // (1)
  a <= 1; // (2)
end

We use to represent "the evaluation event of expression " and to represent "the update event of object ". Therefore, the statement marked (1) in the above example can be decomposed into two events: and . Similarly, the statement marked (2) can be decomposed into two events: and . Applying the above order rules, we can draw the following conclusions:

Considering Order Rule 1, it should be that and .
Considering Order Rule 2, it should be that and .
Considering Order Rule 3, it should be that .
Considering Order Rule 4, it should be that .

Synthesizing these conclusions, there is one and only one possible order: . That is, in this example, the simulator can only process events in this order. Therefore, during the simulation, the object a will first be assigned 0, and then be assigned 1.

Simulators and Simulation Programs

Recall the running light example, and let us analyze the event processing order in it.

module light(
  input clk,
  input rst,
  output reg [15:0] led
);
  reg [31:0] count;
  always @(posedge clk) begin
    if (rst) begin led <= 1; count <= 0; end
    else begin
      if (count == 0) led <= {led[14:0], led[15]};
      count <= (count >= 5000000 ? 32'b0 : count + 1);
    end
  end
endmodule

Assume that a rising edge of clk arrives. In this simulation time, the following events may occur:

Applying the above order rules, we can draw the following conclusions:

When rst = 1, it should be that .
When rst = 0 and count = 0, it should be that .
When rst = 0 and count != 0, it should be that .

After obtaining the above event processing order, we can directly implement this order with C code. The two macros EVAL() and UPDATE() defined in it implement the semantics of the evaluation event and the update event respectively:

#define EVAL(c, name, val) do { \
                             c->CONCAT(name, _next) = (val); \
                             c->CONCAT(name, _update) = 1; \
                           } while (0)
#define UPDATE(c, name)    do { \
                             if (c->CONCAT(name, _update)) { \
                               c->name = c->CONCAT(name, _next); \
                             } \
                           } while (0)

static void cycle(Circuit *c) {
  c->led_update = 0;
  c->count_update = 0;
  if (c->rst) {
    EVAL(c, led, 1);
    EVAL(c, count, 0);
  } else {
    if (c->count == 0) {
      EVAL(c, led, (BITS(c->led, 14, 0) << 1) | BITS(c->led, 15, 15));
    }
    EVAL(c, count, c->count >= 5000000 ? 0 : c->count + 1);
  }
  UPDATE(c, led);
  UPDATE(c, count);
}

Although this C code implements the function of simulating the running light circuit, it does not contain the concept of an "event queue": the events defined in the Verilog Standard Manual are not taken out from a queue in this C code, but are directly "flattened" in the C code in a certain order, and this order conforms to the conventions of the Verilog Standard Manual. In fact, the definition of the event queue in the Verilog Standard Manual is logical:

The Verilog event queue is logically segmented into five different regions.

Therefore, a simulation program does not necessarily have to explicitly maintain the order among events through a queue data structure; as long as the event processing order conforms to the conventions of the Verilog Standard Manual, the behavior of the simulation program conforms to the specification of the manual.

The above simulation method of "flattening" events in a certain order is called "cycle simulation". This simulation method is carried out with the cycle as the granularity, evaluating all the components in the circuit in each simulation cycle. The evaluation order is determined before the simulation starts, and belongs to the static scheduling of events. Since the events have already been "flattened" in a certain order, there is no need to schedule events during the simulation. On one hand, this saves the scheduling overhead; on the other hand, after the events are "flattened", the simulation program also has more opportunities for optimization, so the simulation efficiency is higher. However, the cycle simulation method does not support timing information, so it can only be used for functional verification of synchronous circuits. The open-source simulator Verilator adopts this simulation method.

Understand the behavior of the simulation program generated by Verilator

Compile the running light circuit with Verilator, and try to understand the behavior of the generated C++ code.

In contrast, the reference implementation of the event processing engine provided in the Verilog Standard Manual mentioned above is called "event simulation". In event simulation, the evaluation order of the circuit is determined during the simulation process, which belongs to the dynamic scheduling of events. Therefore, extra overhead is needed during the simulation to maintain the event queue and schedule events. Compared with the cycle simulation method, the simulation efficiency is lower. However, due to the existence of the event queue, the event simulation method supports timing information, and can be used for functional verification and timing verification of synchronous circuits, asynchronous circuits, and mixed circuits. The open-source simulator iVerilog and most commercial simulators (such as VCS) adopt this simulation method.

Data Races

A valid real-world circuit should produce consistent outputs even when its various components work in parallel. Therefore, this also requires that the circuit model, under the aforementioned indeterminacy, should obtain consistent results no matter in what order these events are processed. Conversely, if there exist two different event processing orders that lead to inconsistent simulation results, then there is a data race. The Verilog Standard Manual calls this a "race condition", whose meaning is the same as a data race. In general, if a data race exists during the simulation, the circuit model described is not a valid real-world circuit.

Consider the following example:

always @(posedge clk or negedge rstn) begin
  if (!rstn) a = 1'b0;
  else a = b; // (1)
end

always @(posedge clk or negedge rstn) begin
  if (!rstn) b = 1'b1;
  else b = a; // (2)
end

There are two always blocks in the code, that is, there are two processes. Assume that at a certain time there are a = 0, b = 1, rstn = 1, and a rising edge of clk arrives. Considering that the evaluation operation and the update operation of a blocking assignment are completed together, we use a new operation to represent it. Therefore, the statements marked (1) and (2) can be decomposed into the following events:

According to the definition of the Verilog Standard Manual, the processing order of multiple active events is arbitrary, so the other order rules cannot be applied. We can list all the possible event processing orders:

, resulting in a = 1, b = 1
, resulting in a = 0, b = 0

It can be seen that there is a data race in the above code. When the simulator chooses different event processing orders, it will lead to different simulation results. This is somewhat similar to the unspecified behavior in the C language. Different simulation results may appear in different simulators, in different versions of the same simulator, in multiple runs of the same version of the same simulator, and even in different simulation times of a single run of the same version of the same simulator. All these cases conform to the conventions of the Verilog Standard Manual. It can be seen that if there is a data race in the Verilog code, the simulation result may be hard to predict.

Analyze the Behavior of Verilog Code Using the Event Model (2)

Change the blocking assignments in the above code to non-blocking assignments, and try to re-analyze the possible event processing orders and their results. Does the modified code still have data races? Why?

always @(posedge clk or negedge rstn) begin
  if (!rstn) a <= 1'b0;
  else a <= b;
end

always @(posedge clk or negedge rstn) begin
  if (!rstn) b <= 1'b1;
  else b <= a;
end

Consider the following example:

always @(posedge clk or negedge rstn) begin
  if (!rstn) a = 1'b0;
  else a = 1;
end

always @(posedge clk) begin
  $display("a = %d", a);
end

Assume that at a certain time there are a = 0, rstn = 1, and a rising edge of clk arrives. According to a similar analysis process, we can obtain 2 events:

Note the processing event of the $display system task, that is, . We can list all the possible event processing orders:

, outputs a = 1
, outputs a = 0

It can be seen that there is a data race in the above code. Although it has nothing to do with the behavior of the circuit itself, when the simulator chooses different event processing orders, it will still lead to different simulation results. This may bring confusion to developers' debugging.

Analyze the Behavior of Verilog Code Using the Event Model (3)

Change $display in the above code to $strobe, and try to re-analyze the possible event processing orders and their results. Does the modified code still have data races? Why?

always @(posedge clk or negedge rstn) begin
  if (!rstn) a = 1'b0;
  else a = 1;
end

always @(posedge clk) begin
  $strobe("a = %d", a);
end

In fact, we can summarize the sufficient and necessary conditions for the existence of a data race from the above examples. A data race exists in the Verilog code if and only if there are two events and related to the same object , which simultaneously satisfy:

The processing order between and is indeterminate
In and , at least one event will update

Good Verilog Coding Styles

To eliminate data races, it is necessary to eliminate the events that satisfy the above conditions. However, as the project scale becomes complex, it is very difficult to manually judge whether there is a data race in the code. To cope with this challenge, many Verilog books and related materials recommend some good coding standards. If developers follow these coding standards, most of the data races in the code can be eliminated, making it more likely to design circuits whose behavior conforms to expectations.

For example, the article "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!"open in new window puts forward the following Verilog coding suggestions, and mentions that adopting these suggestions can eliminate more than 90% of data races:

Use non-blocking assignments when modeling sequential circuits.
Use non-blocking assignments when modeling latch circuits.
Use blocking assignments when building combinational logic models with always blocks.
Use non-blocking assignments when building both sequential and combinational logic circuits in the same always block.
Do not use both non-blocking and blocking assignments in the same always block.
Do not assign values to the same variable in more than one always block.
Use the $strobe system task to display the values of variables assigned with non-blocking assignments.
Do not use #0 delays in assignments.

After understanding the event model, we can analyze the principles behind these suggestions:

The reason for using non-blocking assignments to describe sequential logic elements is that the update events of non-blocking assignments are processed only after the events in and have been handled. This characteristic matches the property of "sequential logic elements performing writes only when the next clock arrives".
Latches are not used much in synchronous circuits, so we will not elaborate here.
The reason for using blocking assignments to describe combinational elements is that the update events of blocking assignments are processed immediately in , so other events can immediately see the updated results of blocking assignments, and can use the updated results for subsequent evaluations. This characteristic matches the property of "combinational logic elements' outputs changing immediately when inputs change".
This is related to the synthesizable semantics of Verilog, which will be further discussed below.
Like the previous suggestion, this suggestion is also related to the synthesizable semantics of Verilog, which will be further discussed below.
Different always blocks belong to different processes, and the evaluation order among different processes is indeterminate. In addition, assigning a value to a variable will generate an update event, which exactly satisfies the sufficient and necessary conditions for a data race, so a data race is bound to occur.
The update events of non-blocking assignments belong to , while the events of the $strobe system task belong to . Therefore, the $strobe system task can output the values of variables after they are updated by non-blocking assignments.
The events generated by #0 belong to , and their processing timing is between and . If you do not understand the event processing order, you may write code whose behavior does not match your expectations.

I can write Verilog, so why do I need to know this?

At the very beginning of this section, several Verilog coding suggestions or descriptions were mentioned, but some of them are incorrect. Please try to find them out and analyze why they are incorrect:

Using #0 can force an assignment to be delayed until the end of the current simulation time.
In the same begin-end statement block, performing multiple non-blocking assignments to the same variable results in undefined behavior.
When describing combinational logic elements with an always block, non-blocking assignments cannot be used.
A variable cannot be assigned in multiple always blocks.
It is not recommended to use the $display system task, because sometimes it cannot correctly output the value of a variable.
$display cannot output the result of a non-blocking assignment statement.

More Examples and Analyses

The article "Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!"open in new window also lists many examples and analyses. If you plan to use Verilog, we strongly recommend that you read it.

I can write Verilog, so why do I need to know this? (2)

Of course, even if you follow many suggestions, there will always be that 10% probability of accidentally writing code with data races. When you understand the details of the event model, you will have the ability to independently analyze and resolve data races in the code.

Moreover, it only takes about 1 hour to understand this content. Compared with the time you will spend on debugging in the future, this 1 hour is negligible. Just from the point that "it may help you avoid several days of debugging without knowing why", this 1 hour of investment is absolutely worthwhile.

Logic Synthesis - From RTL Code to Netlist

RTL code is just a description of the circuit, and simulation is only using a program to simulate the behavior of the circuit. If the circuit needs to be manufactured, the wafer fab needs much more detailed information. Specifically, what the wafer fab needs is a layout file in GDSII (Graphic Design System II) format, which describes the physical position of each element in the circuit, for example, there is an AND gate at coordinate (3, 4), and a wire between coordinates (4, 2) and (0, 2). To convert RTL code into such a GDS layout, a series of EDA tools are required to process it in multiple stages. For example, the "placement" stage is needed to determine the coordinate of each gate circuit, and the "routing" stage is needed to determine how to connect the gate circuits through nets.

Usually, the wafer fab will provide a Process Design Kitopen in new window (PDK for short), which contains a series of resources such as device models, design rules, process constraints, verification files, and standard cell libraries under a specific process node. Physical design engineers usually use the PDK to design circuits that conform to the wafer fab's manufacturing specifications. The standard cell library in the PDK contains the logic units supported by this process, called standard cells. Standard cells are part of the objects described in the GDS layout file mentioned above, and they are also the smallest units processed by EDA tools.

Logic synthesis (also simply called "synthesis") refers to the process of converting an RTL description into standard cells. In addition, the GDS layout file also records the connection relationships (i.e., topological structures) between standard cells through wires. These connection relationships are first described in the RTL code (i.e., the connection relationships between circuits and modules), so the synthesizer also needs to include them in the synthesis results for use by subsequent stages, and ultimately pass them to the GDS layout file. In summary, the output of the synthesizer is a netlist of standard cells, which records not only the converted standard cells but also their connection relationships.

You already used ECC in the E stage to synthesize and evaluate the NPC.

ECC uses the open-source RTL synthesizer yosysopen in new window to synthesize RTL code, and maps the synthesis results to a 55nm open-source PDK ICsprout55open in new window.

The first open-source PDK in China, and the most advanced open-source PDK in the world at the time of release

ICsprout55 is an open-source PDK independently developed by Zhejiang Chuangxin Integrated Circuit Co., Ltd. and released in October 2025 with the assistance of the ECOS team of the Institute of Computing Technology, Chinese Academy of Sciences. ICsprout55 is built on mature 55nm CMOS process technology, is the first open-source PDK released in China, and is also the most advanced open-source PDK in the industry at the time of release. It is an important breakthrough for the global open-source chip ecosystem.

The "One Student One Chip" lecture notes once used another open-source PDK, nangate45. However, that PDK is only oriented towards academic research; the quantity and quality of its standard cells also lag behind commercial PDKs, and it cannot be used for tape-out, with no fab using it in production lines. Now the release of ICsprout55 fills the gap in this field in our country, taking us a big step closer to the goal of "completing the tape-out of a fully open-source processor chip based on open-source IP + open-source SoC + open-source EDA + open-source PDK".

Thanks to Zhejiang Chuangxin Integrated Circuit Co., Ltd. for their contribution to the open-source chip field!

You can first decompress this file using the gunzip command, and then open the resulting .v file. After experiencing the synthesis process through an example, we can look at the synthesized netlist file. Find the synthesis result in the result directory and open the .netlist.v file in it. You can see that many signals are defined in bit units in the netlist file, and many submodules with names similar to NOR2X0P5H7L, OAI22X6H7L are instantiated. These submodules are the standard cells provided by the ICsprout55 PDK.

So, how does the synthesizer convert RTL code into a netlist? We will use the following counter as an example to introduce the synthesis process of the synthesizer yosys. Here we provide the yosys official manualopen in new window for everyone to consult when needed.

// counter.v
module counter(
  input clk,
  input rst,
  input en,
  output reg [1:0] count
);
  always @(posedge clk) begin
    if (rst) count <= 2'd0;
    else if (en) count <= count + 2'd1;
  end
endmodule

Parsing

You can make yosys read and parse the source file with the following command:

$ yosys counter.v

-- Parsing `counter.v' using frontend ` -vlog2k' --

1. Executing Verilog-2005 frontend: counter.v
Parsing Verilog input from `counter.v' to AST representation.
Storing AST representation for module `$abstract\counter'.
Successfully finished Verilog frontend.

yosys>

As you can see, yosys parses counter.v and converts it into an abstract syntax tree (AST), then outputs the command prompt yosys>. If you want to exit yosys, you can type exit after the command prompt.

The process of parsing source files is very similar to compiling C language, including lexical analysis and syntax analysis. If you remove one of the semicolons ; in the source file and rerun the command, you will find that yosys reports the following error:

counter.v:10: ERROR: syntax error, unexpected TOK_ELSE

Elaboration

The work of the elaboration stage includes parsing the instantiation relationships between modules, calculating the parameters of module instances, and completing the instance names and port bindings of module instantiations, and so on.

You can make yosys carry out elaboration with the following command:

yosys> hierarchy -check -top counter

2. Executing HIERARCHY pass (managing design hierarchy).

3. Executing AST frontend in derive mode using pre-parsed AST for module `\counter'.
Generating RTLIL representation for module `\counter'.

3.1. Analyzing design hierarchy..
Top module:  \counter

3.2. Analyzing design hierarchy..
Top module:  \counter
Removing unused module `$abstract\counter'.
Removed 1 unused modules.

As you can see, the hierarchy command also needs to specify a top-level module. yosys will take this top-level module as the starting point and expand all instantiated submodules in turn, thereby determining the boundary of the entire design; modules that are not instantiated will be removed. At the same time, the elaboration stage also converts the AST of the entire design into RTLIL, an intermediate language of yosys, which is very similar to the intermediate code generation stage in C language compilation.

Semantic Analysis

We can guess that work similar to the semantic analysis in C language compilation is also carried out in the elaboration stage of yosys. For example, if you change posedge clk in counter.v to posedge counter, yosys will report the following error when executing the above hierarchy command:

counter.v:8: ERROR: Found posedge/negedge event on a signal that is not 1 bit wide!

If you add a module instantiation statement mymodule abc(clk, rst); to counter.v, yosys will report the following error when executing the above hierarchy command:

ERROR: Module `\mymodule' referenced in module `\counter' in cell `\abc' is not part of the design.

As you can see, both types of errors conform to Verilog syntax, so they cannot be discovered in the file parsing stage.

Intermediate Code Generation

After the hierarchy command is executed successfully, we can view the RTLIL of the entire design. By executing the dump command, yosys will output the RTLIL of the current design to the terminal in text form:

yosys> dump

Or output the RTLIL to a file with the write_rtlil command:

yosys> write_rtlil counter.rtlil

Taking the counter.rtlil file as an example, its content is as follows:

autoidx 3
attribute \hdlname "counter"
attribute \top 1
attribute \src "counter.v:2.1-12.10"
module \counter
  attribute \src "counter.v:8.3-11.6"
  wire width 2 $0\count[1:0]
  attribute \src "counter.v:10.27-10.39"
  wire width 2 $add$counter.v:10$2_Y
  attribute \src "counter.v:3.9-3.12"
  wire input 1 \clk
  attribute \src "counter.v:6.20-6.25"
  wire width 2 output 4 \count
  attribute \src "counter.v:5.9-5.11"
  wire input 3 \en
  attribute \src "counter.v:4.9-4.12"
  wire input 2 \rst
  attribute \src "counter.v:10.27-10.39"
  cell $add $add$counter.v:10$2
    parameter \A_SIGNED 0
    parameter \A_WIDTH 2
    parameter \B_SIGNED 0
    parameter \B_WIDTH 2
    parameter \Y_WIDTH 2
    connect \A \count
    connect \B 2'01
    connect \Y $add$counter.v:10$2_Y
  end
  attribute \src "counter.v:8.3-11.6"
  process $proc$counter.v:8$1
    assign $0\count[1:0] \count
    attribute \src "counter.v:9.5-10.40"
    switch \rst
      attribute \src "counter.v:9.9-9.12"
      case 1'1
        assign $0\count[1:0] 2'00
      attribute \src "counter.v:10.5-10.9"
      case
        attribute \src "counter.v:10.10-10.40"
        switch \en
          attribute \src "counter.v:10.14-10.16"
          case 1'1
            assign $0\count[1:0] $add$counter.v:10$2_Y
          case
        end
    end
    sync posedge \clk
      update \count $0\count[1:0]
  end
end

We will explain the output RTLIL a little. For more content about RTLIL, you can consult the relevant yosys manualopen in new window:

attribute is used to identify some attributes. For example, attribute \src "counter.v:10.27-10.39" is used to identify the position of the corresponding element in the source file, that is, from column 27 to column 39 of line 10 in counter.v.
wire width 2 $0\count[1:0] means defining a signal with a bit width of 2, whose name is $0\count[1:0] (note that the characters $, \, [, : and ] are all part of the name).
cell $add $add$counter.v:10$2 means instantiating a cell of type $add, whose name is $add$counter.v:10$2. The specific parameters of the cell are represented by parameter. For example, parameter \A_WIDTH 2 means that the bit width of port A of the cell is 2, and parameter \A_SIGNED 0 means that port A of the cell is unsigned. The port connection relationship is represented by connect. For example, connect \Y $add$counter.v:10$2_Y means that port Y of the cell is connected to the signal $add$counter.v:10$2_Y.
process represents a behavioral description process, in which assign represents the assignment of a signal, switch-case represents performing conditional assignment according to the value of a signal, and sync represents updating a signal when the condition is satisfied.

As you can see, although the syntax of RTLIL is different from that of Verilog, we can still feel that RTLIL is also describing hardware, and can even feel that process corresponds to the always in Verilog code. However, some operators have been replaced by cells, for example, + is replaced by $add. Therefore, compared with the input Verilog code, the current RTLIL is closer to the netlist. Cells like $add belong to the internal cell library of yosysopen in new window.

We can also visualize the topological relationships in the RTLIL through a structure diagram. However, before this, you may need to install a viewing tool for Graphviz dot type files:

apt-get install xdot

Then, you can execute the show command in yosys, which will automatically call tools like xdot to open the structure diagram:

yosys> show

The structure diagram file generated by the show command is saved in ~/.yosys_show.dot by default. Executing the show command multiple times will overwrite it. You can manually copy it to another directory and open it with the xdot tool.

View Structure Diagram

Use the show command to view the current structure diagram, so as to understand RTLIL.

Coarse-grain Synthesis

The coarse-grain synthesis stage is responsible for processing based on the "coarse-grain representation" of the design. Here, the coarse-grain representation refers to describing the design with word-level cellsopen in new window. Word-level cells are part of the internal cell library of yosys. These cells are at a relatively high abstraction level and support multi-bit widths and parameter functions. In terms of naming style, word-level cells are usually named with a $ prefix. The $add cell mentioned above belongs to word-level cells. Other word-level cells include $shift (shift operation), $mux (selection operation), and so on.

Converting Procedural Descriptions to Coarse-grain Representations

However, the current RTLIL still contains procedural descriptions like process (represented by PROC nodes in the structure diagram). They do not belong to the coarse-grain representation, and the processing work related to the coarse-grain representation cannot be carried out on them. Therefore, yosys still needs to first convert all procedural descriptions into coarse-grain representations, which can be achieved with the proc command:

yosys> proc

The proc command is actually a macro command, which sequentially calls a series of subcommands to complete the conversion of procedural descriptions:

Step	Subcommand	Description
1	`proc_clean`	Remove empty branches and empty procedural descriptions
2	`proc_rmdead`	Remove unreachable `case` branches
3	`proc_prune`	Remove redundant assignment operations (overwritten by subsequent assignment operations)
4	`proc_init`	Convert `init` operations in procedural descriptions into `init` attributes on the corresponding signals
5	`proc_arst`	Identify asynchronous resets
6	`proc_rom`	Convert `switch` operations in procedural descriptions into ROM when appropriate
7	`proc_mux`	Convert `switch` operations in procedural descriptions into `$mux` cells (multiplexers)
8	`proc_dlatch`	Convert latches in procedural descriptions into D-latch type cells
9	`proc_dff`	Convert flip-flops in procedural descriptions into D flip-flop type cells
10	`proc_memwr`	Convert memory write operations in procedural descriptions into `$memwr` cells
11	`proc_clean`	Remove empty branches and empty procedural descriptions
12	`opt_expr -keepdc`	Perform expression-related optimizations

Some subcommands are very similar to the compilation optimization techniques of C language, which should not be difficult for you to understand. Overall, the proc command mainly converts the switch-case parts of the procedural descriptions in the RTLIL into $mux cells, and converts the sync descriptions into D-latch type or D flip-flop type cells, thereby obtaining a complete coarse-grain representation.

View Structure Diagram (2)

Use the show command to view the current structure diagram, and compare the difference before and after executing the proc command.

Optimization

Similar to compilation optimization, synthesizers generally also provide optimization functions, allowing developers to focus on architecture design and logic design without having to consider the performance of the circuit too much during the design stage. Synthesizers can usually provide a fairly good performance floor.

After obtaining a complete coarse-grain representation, a series of optimizations can be applied to generate a better design. This can be achieved with the opt command:

yosys> opt

Similar to the proc introduced above, opt is also a macro command, which sequentially calls a series of subcommands to carry out various optimizations:

Step	Subcommand	Description
1	`opt_expr`	Constant folding and simple expression rewriting
2	`opt_merge -nomux`	Merge identical cells, but not selector-type cells
	`do`	Start the loop
3	`opt_muxtree`	Remove unreachable branches in nested selectors
4	`opt_reduce`	Simplify multi-input selectors, AND gates, and OR gates
5	`opt_merge`	Merge identical cells
6	`opt_share`	Merge cells with the same inputs, the same type, and no simultaneous activation
7	`opt_dff`	Constant optimization of D flip-flops and merging of clock/reset signals
8	`opt_clean`	Remove useless cells and nets
9	`opt_expr`	Constant folding and simple expression rewriting
	`while (changed)`	If the design has changed, jump to step 3 to continue the loop

Here are some common optimization techniques. For ease of understanding, we use Verilog code to present the semantics before and after optimization.

Constant folding and simple expression rewriting (opt_expr) - In some expressions, if an input is a specific constant, or the expression conforms to some special pattern, it can be simplified. In the following example, the result of the expression a != a must be 0, so it can be optimized to assign x = 1'b0; further, after applying the constant propagation optimization technique, the result of the expression b | x must be b, so it can be optimized to assign y = b;; in addition, since the bit width of c is 1, the expression c == 0 is equivalent to ~c, so it can be optimized to assign z = ~c;. The synthesizer can replace these cells with the calculation results, thereby simplifying the corresponding circuit.

//          before optimization     |            after optimization
  wire a, b, c, x, y, z;       |    wire a, b, c, x, y, z;
  // ......                    |    // ......
  assign x = a != a;           |    assign x = 1'0;
  assign y = b | x;            |    assign y = b;
  assign z = c == x;           |    assign z = ~c;

Merging identical cells (opt_merge) - For multiple cells with identical functions and inputs, they can be merged into one cell, letting its output drive the original output signals, thereby reducing the number of cells. In the following example, the two cells of a + b and b + a have identical functions and inputs, so x can directly drive y, thereby reducing one addition cell.

//          before optimization     |            after optimization
  wire a, b, x, y;             |    wire a, b, x, y;
  // ......                    |    // ......
  assign x = a + b;            |    assign x = a + b;
  assign y = b + a;            |    assign y = x;

Trade-off Between Area and Performance

It should be noted that although this optimization reduces the number of cells, it increases the fan-out of the cell (i.e., the number of downstream cells connected to the output of this cell). With other conditions unchanged, an increase in fan-out will raise the circuit delay.

To use a real-life analogy, the output of a cell is like a faucet that provides water flow to a downstream pool. Only when the pool is full of water can the gate be pushed open, similar to making the downstream transistors flip. Before the optimization, the two faucets each provide water flow to their own downstream pools; after the optimization, the number of faucets is saved, but it needs to provide water flow to the two downstream pools at the same time. With the water flow speed unchanged, it takes longer to fill the two pools, and this time is similar to the circuit delay.

In situations where delay needs to be optimized, the method of "duplicating cells" is instead used to increase the number of faucets. Therefore, whether to merge cells or duplicate cells is actually a trade-off between area and performance.

Removing unreachable branches in nested selectors (opt_muxtree) - In nested selectors, some branches are unreachable due to conflicting conditions and can be removed. In the following example, the result of the inner selector a ? b : c cannot be c, because this requires the outer selection signal a = 1 while the inner selection signal a = 0, which is contradictory. Therefore, the inner selector cell can be replaced with b, thereby simplifying the corresponding circuit.

//          before optimization     |            after optimization
  wire a, b, c, d, x;             |    wire a, b, c, d, x;
  // ......                       |    // ......
  assign x = a ? (a ? b : c) : d; |    assign x = a ? b : d;

Simplifying multi-input selectors, AND gates, and OR gates (opt_reduce) - For multi-input selectors, AND gates, and OR gates, some of their inputs may be identical, and these inputs can be eliminated or merged. In the following example, before optimization, a selection needs to be made between two 32-bit signals to obtain imm, but for these two signals, their bits 12 to 31 are respectively the same as bit 11 (one is 0, the other is inst[31]). Therefore, the inputs of the selector can be optimized: first select the part of bits 0 to 11 as imm[11:0], and then use the selected bit 11 as imm[31:20]. After optimization, the bit width of the data side of the selector is reduced from 32 to 12. Similarly, when performing reduce AND with &imm, since bits 12 to 31 of the input imm are the same as bit 11, bits 12 to 31 of the input can be directly removed, and the result is the same as &imm[11:0]. After optimization, the bit width of the input of the AND gate is reduced from 32 to 12.

//          before optimization     |            after optimization
  wire [31:0] inst, imm;          |    wire [31:0] inst, imm;
  wire sel, x;                    |    wire sel, x;
  // ......                       |    // ......
  assign imm = !sel ? 32'b0 :     |    assign imm[11:0] = !sel ? 12'b0 : inst[31:20];
    {{20{inst[31]}}, inst[31:20]};|    assign imm[31:20] = {20{imm[11]}};
  assign x = &imm;                |    assign x = &imm[11:0];

Constant optimization of D flip-flops (opt_dff) - If the data input of a D flip-flop is a constant, it can be replaced with the constant, thereby removing the corresponding D flip-flop cell. In the following example, the data input of the D flip-flop r is a constant, so it can be directly optimized into a constant signal.

//          before optimization     |            after optimization
  reg [31:0] r;                   |    wire [31:0] r;
  // ......                       |    // ......
  always @ (posedge clk)          |    assign r = 32'hdeadbeef;
    r <= 32'hdeadbeef;            |

Removing useless cells and nets (opt_clean) - If some cells and nets do not affect the output of the module, they can be removed. In the following example, the net t does not affect the output port x of the module, so it can be removed together with the cell a & b.

//          before optimization     |            after optimization
  module m(                       |    module m(
    input a, b;                   |      input a, b;
    output x;                     |      output x;
  );                              |    );
    wire t;                       |      assign x = a + b;
    assign x = a + b;             |    endmodule
    assign t = a & b;             |
  endmodule                       |

Besides the techniques introduced above, there are many other optimization techniques used in the synthesis process, such as bit-width reduction and peephole optimization. We will not elaborate on them here. Students who are interested can consult the yosys documentationopen in new window or related materials.

View Structure Diagram (3)

Use the show command to view the current structure diagram, and compare the difference before and after executing the opt command.

Identification and Processing of Finite State Machines

We previously introduced the state machine model of computer systems, in which it was explained that a digital circuit can also be regarded as a state machine. The finite state machine (FSM) here more specifically refers to the part in the design that is implemented with digital logic and has state machine characteristics.

For example, you should have completed problems similar to "identifying three consecutive 1s" on HDLBits. For this problem, we can list the following state transition table (the table entries mean "next state/output"):

	Meaning	Input `0`	Input `1`
`S0`	Initial state	`S0`/`0`	`S1`/`0`
`S1`	Identified one `1`	`S0`/`0`	`S2`/`0`
`S2`	Identified two `1`s	`S0`/`0`	`S2`/`1`

For some more complex FSMs, they may contain some redundant states, or states, inputs, and outputs that can be merged, but these situations are hard to discover on the word-level cells of the operator category. Therefore, the synthesizer generally first identifies the FSM on the word-level cells, then analyzes and optimizes it on the semantics of the FSM, and finally maps it back to word-level cells.

In yosys, this can be achieved with the fsm command:

yosys> fsm

fsm is also a macro command, which sequentially calls a series of subcommands to carry out the processing of the FSM. The main processing steps include:

fsm_detect - FSM detection, which identifies the FSM in the RTLIL according to certain rules and marks the related cells with special attributes
fsm_extract - FSM extraction, which replaces the marked related cells with $fsm cells and parses out the state transition table
fsm_opt - FSM optimization, which optimizes the FSM according to the state transition table, including removing useless output signals, merging identical upstream input signals, merging different inputs with the same output in the same state, simplifying states according to constant inputs, and so on
fsm_recode - FSM recoding, which re-encodes the state signals with one-hot codes
fsm_map - Cell mapping, which maps the processed $fsm cells back to word-level cells

However, the above counter.v does not contain an FSM, so executing the above fsm command has no effect. Theoretically, according to the state machine model of digital circuits, we can try to regard any digital circuit design as a whole as an FSM and carry out the above processing, but the state transition table parsed out in this way is extremely huge (for a 32-bit register, there are already states), which brings two problems: on one hand, the amount of computation required to process such a state space is already far beyond the computing power of current computers; on the other hand, such states have very low similarity in terms of input, output, and next state, making it almost impossible to find states and signals that can be optimized. Therefore, the state machine model of digital circuits is only used to help us understand the basic principles, and in practice it will not be used for FSM optimization.

Identification and Processing of Memories

Another type of cell that needs special processing is the memory. In yosys, memory-related processing of the RTLIL can be carried out with the memory command:

yosys> memory

memory is also a macro command, which sequentially calls a series of subcommands. The related processing includes merging the flip-flops upstream and downstream into the read-write cells of the memory, merging multiple read-write cells of the memory into one multi-port memory cell, and so on.

In the FPGA flow, since the types of memory devices provided by FPGAs are few (such as LUT RAM, Block RAM, and FF), the FPGA synthesizer can automatically identify the memory in the RTL code through the above method, and map it to the physical memory devices according to the identified memory attributes. Taking advantage of the programmability of FPGAs, the synthesizer can realize on-demand allocation of memory devices, that is, the synthesizer can dynamically calculate how large a memory is needed according to the RTL code and map to them.

But this is not the case for the ASIC flow. In order to improve the performance of memories, the memory cells in the ASIC flow do not contain programmable functions; instead, the standard cell library provides several memories with determined specifications for RTL developers to choose. These memory cells also have different performance, area, and power consumption attributes. For example, to implement a 64x64 memory function at the RTL level, the RTL developer can choose one 64x64 memory cell, or choose two 32x64 memory cells for splicing. The former has a smaller total area, but the read latency may be higher; while the latter has a larger total area, but the read latency is better. In addition, different memory specifications have different shapes, which will also affect the subsequent placement and routing. These mutually restrictive factors make it difficult for the synthesizer to automatically identify and map memories, so RTL developers need to choose the memory specifications by themselves according to the design goals, and manually instantiate the memory cells as submodules in the RTL code.

It can be said that the difference in the way memories are used between the ASIC flow and the FPGA flow reflects the trade-off between performance and flexibility: ASIC pursues higher performance, but has weaker flexibility, making it difficult to realize on-demand allocation, requiring developers to choose the specific specifications by themselves; FPGA has better flexibility, but the programmable function of its memory devices makes its performance not as good as that of ASIC.

However, the above counter.v does not contain a memory, so executing the above memory command has no effect. For some time in the future, we will not come into contact with circuit designs containing such memories. We will discuss the problem of memories again in Phase A.

Fine-grain Synthesis

The fine-grain synthesis stage is responsible for processing based on the "fine-grain representation" of the design. As mentioned above, the so-called fine-grain representation refers to describing the design with gate-level cells. There is a category of gate-level cellsopen in new window in the internal cell library of yosys. Compared with the cells used in the coarse-grain representation, these gate-level cells all have a data bit width of 1 and do not provide parameter functions. In terms of naming style, gate-level cells are usually named in the form of $_XXX_, where XXX is generally in uppercase, so as to be distinguished from word-level cells.

Fine-grain synthesis first needs to convert the coarse-grain representation of the design into a fine-grain representation, which can be achieved with the techmap command:

yosys> techmap

The techmap command is used to replace the cells of the current design with cell implementations in the specified cell library. If no cell library is specified, the command will use the internal gate-level cell library of yosys.

After replacing with gate-level cells, it is also necessary to split some multi-bit nets and ports; otherwise, the RTLIL will contain unnecessary bit extraction and bit concatenation operations. This can be achieved with the splitnets command:

yosys> splitnets -ports

Then, you can execute the opt -full command to let yosys carry out some optimization work to clear the useless cells and nets, and then view the structure diagram.

As you can see, the D flip-flop cell with a bit width of 2 in the coarse-grain representation has been split into two D flip-flop cells with a bit width of 1, and the adder cell $add has also been split into some gate-level cells. Therefore, compared with the coarse-grain representation, the current fine-grain representation is closer to the netlist.

View Structure Diagram (4)

Use the show command to view the current structure diagram, and compare the difference before and after executing the techmap command.

Technology Mapping

Technology mapping refers to mapping from a technology-independent circuit representation to an implementation of a specific technology. Here, the technology mapping stage is responsible for mapping the fine-grain representation of the design to the standard cells of the target technology. To demonstrate the effect of technology mapping, we use a simple example standard cell library, which originates from the yosys manual:

library(demo) {
  cell(BUF) {
    area: 6;
    pin(A) { direction: input; }
    pin(Y) { direction: output;
              function: "A"; }
  }
  cell(NOT) {
    area: 3;
    pin(A) { direction: input; }
    pin(Y) { direction: output;
              function: "A'"; }
  }
  cell(NAND) {
    area: 4;
    pin(A) { direction: input; }
    pin(B) { direction: input; }
    pin(Y) { direction: output;
             function: "(A*B)'"; }
  }
  cell(NOR) {
    area: 4;
    pin(A) { direction: input; }
    pin(B) { direction: input; }
    pin(Y) { direction: output;
             function: "(A+B)'"; }
  }
  cell(DFF) {
    area: 18;
    ff(IQ, IQN) { clocked_on: C;
                  next_state: D; }
    pin(C) { direction: input;
                 clock: true; }
    pin(D) { direction: input; }
    pin(Q) { direction: output;
              function: "IQ"; }
  }
}

Save the above content to the file cell.lib, which describes the attributes of standard cells in text form. The above file contains the following attributes:

The area of the cell, generally in units of
Pins, which also identify the direction; in particular, output pins also contain the function attribute, given by a logical expression; for the clock input pin of a flip-flop, it also contains the clock attribute, used to identify that this pin is a clock signal

In yosys, the technology mapping process is divided into two steps. First, perform technology mapping on the sequential logic cells with the following command:

yosys> dfflibmap -liberty cell.lib

After executing the above command and viewing the structure diagram, you will find that in the fine-grain representation, the gate-level cell $_SDFFE_PP0P_ has been replaced with DFF and some $_MUX_ cells, where DFF is the standard cell in the standard cell library cell.lib. The reason why this step generates extra $_MUX_ cells is that there is no standard cell in cell.lib with a function completely the same as $_SDFFE_PP0P_: consulting the yosys manual, the function of $_SDFFE_PP0P_ is "a positive-edge D flip-flop with an active-high synchronous reset signal and an active-high enable signal", but the only sequential logic cell DFF in cell.lib is just a simple D flip-flop, so some additional combinational logic cells need to be introduced to realize the functions of "active-high synchronous reset signal" and "active-high enable signal".

However, you will find that the output pin Q of the DFF cell appears on the left side (representing the input side) in the structure diagram. This is because cell.lib is an external cell library for yosys, and the show command has no information about the DFF standard cell by default. To fix this problem, we can let yosys read in the cell.lib standard cell library first:

yosys> read_liberty -lib cell.lib

After a successful read-in, execute the show command again to fix this problem.

View Structure Diagram (5)

Use the show command to view the current structure diagram, and compare the difference before and after executing the dfflibmap command.

Next, perform technology mapping on the combinational logic cells with the following command:

yosys> abc -liberty cell.lib

The abc command will call an external tool ABC to carry out the technology mapping of combinational logic cells. All the gate-level cells are replaced with the standard cells in the standard cell library cell.lib. Finally, use the clean command to clear the useless cells and connections, and the final netlist is obtained, thus completing the conversion from RTL code to netlist.

View Structure Diagram (6)

Use the show command to view the current structure diagram, and compare the difference before and after executing the abc command.

Technology Mapping and the techmap Command of yosys

In the previous fine-grain synthesis stage, we introduced the techmap command of yosys, which is actually also the abbreviation of Technology Mapping. The official yosys manual explains Technology Mapping in two steps: the first step is to map word-level cells to gate-level cells, and the second step is to map gate-level cells to the standard cells of the target technology.

This is actually different from the concept of technology mapping introduced in the lecture notes: the understanding of technology mapping in the lecture notes emphasizes more "from abstraction to concreteness". To be consistent with the industry concept, we do not adopt the understanding of technology mapping in the official yosys manual. Therefore, what is described as "the first step of technology mapping" in the official yosys manual actually corresponds to the "fine-grain synthesis" in the lecture notes; while what is described as "the second step of technology mapping" in the official yosys manual actually corresponds to the "technology mapping" in the lecture notes.

Netlist and Report Generation

Finally, write the netlist to a file with the write_verilog command, and output the information of the used standard cells with the stat command:

yosys> write_verilog netlist.v
yosys> stat -liberty cell.lib

Understand the Synthesis Process through the yosys Log File

You have already synthesized the running light project. Try to view the yosys log file in the yosys-sta/result directory, and understand the synthesis process in combination with the above text. Try inspecting Yosys's log file, light/runs/default/Synthesis_yosys/log/Synthesis.log, and use the explanation above to understand the synthesis process.

To avoid repeatedly entering Yosys commands manually, ECC uses a script to drive Yosys during synthesis. You can find the relevant script at ecc/_internal/chipcompiler/tools/yosys/scripts/yosys_synthesis.tcl. If you want to learn more about Yosys commands, you can refer to the official Yosys documentation or enter help xxx in the Yosys command-line interface to view information about the xxx command. If you want to further understand yosys commands, you can consult the yosys official manual, or type help xxx in the yosys command line to view the relevant information of the xxx command.

RTL Synthesis Semantics of Verilog

What kind of RTL code is converted into what kind of standard cells requires considering the semantics of RTL synthesis. But the Verilog Standard Manual defines the simulation semantics of Verilog, which is not applicable to the scenario of RTL synthesis. For this reason, the Verilog RTL Synthesis Standard Manualopen in new window specifically describes the semantics of the Verilog language in the synthesis scenario. The synthesizer reads the Verilog code, and then converts the Verilog code into semantically equivalent standard cells according to the semantics described in this standard manual.

Section 1.1 of the Verilog RTL Synthesis Standard Manual introduces the background of RTL synthesis:

This standard defines a set of modeling rules for writing Verilog® HDL descriptions
for synthesis. Adherence to these rules guarantees the interoperability of Verilog
HDL descriptions between register-transfer level synthesis tools that comply to this
standard. The standard defines how the semantics of Verilog HDL are used, for
example, to describe level- and edge-sensitive logic. It also describes the syntax
of the language with reference to what shall be supported and what shall not be
supported for interoperability.

Use of this standard will enhance the portability of Verilog-HDL-based designs
across synthesis tools conforming to this standard. In addition, it will minimize
the potential for functional mismatch that may occur between the RTL model and the
synthesized netlist.

Some key information includes:

This standard describes which parts of the Verilog syntax need to be supported by synthesizers and which parts are not supported. This shows that the Verilog syntax supported by synthesizers is only a subset of the overall Verilog syntax.
Adopting this standard can improve the portability of Verilog designs across different synthesizers, so that compliant synthesizers can parse compliant Verilog code with consistent semantics.
Adopting this standard can also minimize, as much as possible, the potential risk of functional inconsistency between the RTL model and the synthesized netlist.

RTFM

Read Chapter 5 Modeling hardware elements of the Verilog RTL Synthesis Standard Manual to understand what kind of Verilog code is synthesized into what kind of circuit.

This part of content is only about 10 pages, but it is more authoritative than all other Verilog learning materials, and provides a large number of code examples and explanations, even giving detailed explanations of in which usage scenarios x and z are synthesizable.

In fact, some of the Verilog coding suggestions quoted above are put forward based on the specifications of the Verilog RTL Synthesis Standard Manual.

Since the semantics of simulation and synthesis are not completely consistent, it is possible that the same Verilog code behaves inconsistently in the two scenarios of simulation and synthesis. In the chip design flow, both simulation and synthesis are necessary steps, and considering physical design and manufacturing, the behavior of the Verilog code we design needs to be based on synthesis. This requires us to avoid writing code that behaves inconsistently in the two scenarios of simulation and synthesis.

Appendix B Functional mismatches of the Verilog RTL Synthesis Standard Manual describes some scenarios in which such problems occur. Section B.1 mentions uncertain behaviors, with the following examples:

always @(posedge clock) begin
  a = 0;
  a = 1;
end

always @(posedge clock)
  b = a;

Analyze the Behavior of Verilog Code Using the Event Model (4)

Try to use the event model to analyze why there is a data race in the above code.

In this example, the synthesizer can freely choose either 0 or 1 as the input of the flip-flop b. But no matter how it chooses, due to the existence of the data race, the behavior of the synthesized netlist may be inconsistent with the simulation result.

RTFM (2)

Read Appendix B of the Verilog RTL Synthesis Standard Manual to understand what other situations can cause functional mismatches between the synthesized netlist and the simulation behavior.

Chisel Benefits

If you plan to use the Chisel language to design circuits, you do not need to consider the data races and functional mismatches mentioned above, because the semantics of the Chisel language guarantee that the generated Verilog code is free of these problems.

Evaluating Circuits with Open-Source EDA Tools

Since the standard cells in the netlist are manufacturable and have various physical attributes, after obtaining the netlist, we can make a preliminary evaluation of whether the circuit is good or bad. There are multiple dimensions to measure whether a circuit is good, and the three commonly used dimensions are performance, power consumption, and area, collectively called PPA (Performance, Power, Area).

Area Evaluation

The simplest is area evaluation. The .lib file has already given the area attributes of standard cells. The synthesizer only needs to count the number of times each standard cell is instantiated in the netlist to calculate the total area of the current design.

Performance Evaluation

The performance of a circuit is mainly measured by frequency, that is, "how many times the circuit can work at most per second". This is determined by "how much time is required at least to complete one work". We define "one work" as "the sequential logic elements updating their states under the drive of the clock signal". Because these indicators are related to time, the process of analyzing them is also called timing analysis.

Recall the state machine model of digital circuits: sequential logic elements will update their states when the clock signal arrives. The "state" here is essentially data, which needs to be calculated through combinational logic. But the calculation of combinational logic requires a certain delay, so we need to control the clock frequency well so that the interval between two clocks (i.e., the period) can sufficiently accommodate the delay of the combinational logic; otherwise, the data signal used to update the state is not a stable result calculated by the combinational logic, so the behavior of the circuit during operation does not match our design expectations.

    +------------------+
+-->| Sequential Logic |----+
|   +------------------+    |
| next state                | current state
|                           |
|  +---------------------+  |
+--| Combinational Logic |<-+
   +---------------------+

Therefore, evaluating the performance of a circuit is to deduce the highest frequency at which the circuit can work by evaluating the delay of the combinational logic in the circuit. If the actual working frequency of the circuit is higher than this highest frequency, the new states of some sequential logic elements in the circuit will not match our design expectations, making it impossible for the circuit to work as expected.

The Cost of Faster Speeds

Some electronics enthusiasts will try to overclock their processors, making them run at a frequency higher than the highest frequency claimed by the manufacturer, so as to try to obtain a better computer experience. However, if the overclocking fails, the computer will enter an unstable state and may freeze after running for a period of time.

The essential reason for the freeze is the same as introduced above: because the processor works too fast, some of its sequential logic units are not updated with the expected data, and finally the processor enters an incorrect state.

There are many combinational logic elements in a circuit, and the working frequency of the circuit is limited by the combinational logic path with the longest delay in the circuit. This path is called the "critical path" of the circuit. To find the critical path in the circuit, EDA tools need to read the delay information of standard cells from the standard cell library, then analyze the synthesized netlist, and calculate the total delay of all standard cells on the combinational logic paths; the path with the longest total delay is the critical path of the circuit. This evaluation process can be carried out based on the netlist and the delay information of the standard cell library, and does not involve the working process of the circuit, so it is called static timing analysis (STA, Static Timing Analysis). It should be noted that the cell.lib above is just a simple example, which does not contain delay information, so it cannot be used for static timing analysis.

However, the standard cell library in ICsprout55 has already provided complete delay information of standard cells. After ECC completes synthesis and obtains a netlist mapped to the standard cells in ICsprout55, it passes the netlist and then it inputs the netlist file and the standard cell information file in the PDK into the open-source static timing analysis tool iSTAopen in new window, which will quickly evaluate the path delays in the RTL design and report several paths with the largest gap from the target frequency for the user's reference.

Evaluate the Performance of the Circuit

Try to evaluate the performance of the circuit through the ECC Compiler, and read the static timing analysis report to understand the maximum frequency at which the target circuit can run.

Currently we do not require you to understand all the details in the report; we will introduce more STA content in Phase B. If you are interested in the details of the report now, you can refer to this tutorialopen in new window, or search the Internet for tutorials on reading timing reports. Other tools can also generate timing reports. Although the formats may be different, most of the concepts in them are common.

In fact, the timing report obtained in the above way cannot fully reflect the frequency at the time of chip tape-out. This is because the netlist only contains the standard cells and their topology information, and does not contain the physical position information of the standard cells. It is conceivable that if two standard cells are far apart in physical position, the signal transmitted between them also needs to go through a certain delay to arrive, and this delay is called net delay. And the delay attribute of the standard cells in the standard cell library can only reflect the delay of the signal passing through the standard cells themselves, and this delay is called logic delay. The complete delay information should be composed of logic delay and net delay. That is to say, the frequency obtained by the above evaluation method is only based on logic delay. Only after the EDA tools complete the placement and routing work can accurate net delay information be obtained, thereby evaluating frequency information closer to the tape-out scenario.

Then, is the frequency information currently obtained meaningless? No, it is not. On one hand, carrying out physical design work also requires a certain amount of time. For complex high-performance processors, it may even take several days to complete one round of physical design work. Obviously, to obtain more accurate delay and frequency information, the design team needs to pay more time, which will affect the efficiency of project iteration. On the other hand, although logic delay cannot represent the final delay information, it has already given the upper limit of the frequency, and it can also reflect some problems in the RTL logic design stage, such as overly complex circuit logic. This information is enough to help RTL designers make a preliminary evaluation of the RTL design, so as to carry out rapid iterative optimization. We will further introduce optimization methods in Phase B.

In particular, for a processor, frequency is not the only factor measuring its performance. Another understanding of frequency is how many cycles it works per second, but not every cycle necessarily has "substantial work". The duty of a processor is to execute programs, so for a processor, performance should be interpreted as "the efficiency of executing programs". More specifically, a processor executes the instructions in programs. If the frequency of a processor is very high, but it takes a long time to execute one instruction, then overall it cannot be considered an excellent processor. Therefore, another indicator is needed to measure the efficiency of a processor in executing instructions. This commonly used indicator is called IPC (Instructions Per Cycle), which measures the average number of instructions executed by the processor per cycle. We will further discuss the measurement and optimization methods of IPC in Phase B.

Power Consumption Evaluation

To evaluate the power consumption of a circuit, it is necessary to evaluate the sum of the power consumption of all standard cells in the circuit. EDA tools need to read the power consumption information of standard cells from the standard cell library, calculate the power consumption of each standard cell, and thus calculate the total power consumption of the circuit. Similar to the delay evaluation, the cell.lib above is just a simple example, which does not contain power consumption information, so it cannot be used for power consumption analysis.

Similarly, the standard cell library in ICsprout55 has already provided complete power consumption information of standard cells. The iSTA tool invoked by ECC after synthesis can evaluate not only the performance of the RTL design, but also its power consumption: iSTA will quickly evaluate and report the power consumption of each standard cell and the total power consumption in the RTL design.

Evaluate Circuit Power Consumption

Using the running-light project as an example, the power analysis report is located at light/runs/default/Synthesis_yosys/report/post_synthesis/power.rpt.

Try reading this report and familiarize yourself with the circuit's power consumption information.

The power consumption report reports three types of power consumption, among which:

Internal Power is internal power consumption. When transistors flip, since nMOS and pMOS do not complete the state switch instantaneously, within a very short period of time, nMOS and pMOS will be conducting at the same time, resulting in a short-circuit current from the power supply end to the ground end. The power consumption generated by this part of current is internal power consumption, also called short-circuit power. Internal power consumption is part of dynamic power.
Switching Power is switching power consumption. When a CMOS circuit flips, in order to complete the change from 0 to 1 or from 1 to 0, the corresponding equivalent capacitance needs to be charged or discharged. The power consumption generated by this process is switching power, also called switch power. Switching power is also part of dynamic power, that is, dynamic power consists of two parts: internal power and switching power.
Leakage Power is leakage power consumption. Ideally, when a transistor is in the cut-off state, no current flows between the source and the drain. But in reality this is not the case; real transistors, due to various reasons, will have a certain tiny current between the source and the drain, called leakage current. The power consumption formed by the leakage current is leakage power. Since leakage power also exists when transistors do not flip, it is also called static power.

Limitations of Open-Source EDA Tools

Because the synthesis quality of yosys is not high, and there is still a certain gap compared with commercial synthesizers. However, in the scenario of post-synthesis timing evaluation, the above defects will not cause obvious impact. Even if the synthesis quality of yosys is not high, we can still guide the direction of RTL optimization through the relative improvement of the synthesis results.

So, is an FPGA still needed for learning "One Student One Chip"?

Basically, it is not needed:

In terms of accuracy, the synthesis flow of yosys is oriented towards ASIC design, and both its principles and the accuracy of the reports are more suitable for "One Student One Chip"; while the principles of the FPGA flow are different from those of ASIC and cannot replace the ASIC flow. Even if the FPGA flow is correct, the standard ASIC flow still needs netlist functional simulation and timing simulation.
In terms of time, the main function of FPGA is simulation acceleration. That is, if the simulation task does not need to take a long time to complete, the advantage of using FPGA is not obvious. In fact, from the complete flows of the two, the advantage of FPGA can only be reflected when the following inequality holds:

Among them, usually reaches the order of hours, while can usually be completed within a few minutes. Therefore, the above inequality can only possibly hold when reaches the order of hours. However, in the study of "One Student One Chip", it is hard for you to encounter simulation tasks that need hours to complete. And when you do encounter such tasks, we will also put forward higher requirements for the FPGA evaluation process. We will continue to discuss this problem in Phase B.

In terms of debugging difficulty, the debugging means of FPGA are very limited, and only the low-level waveform information can be captured under the conditions of limited time and space; on the contrary, software simulation is much more flexible, and we can use many software methods to improve debugging efficiency from various aspects.

PDK and Standard Cell Library

The cell.lib we just mentioned is only a simple example of a standard cell library. Now let us introduce the PDK ICsprout55. You have already come into contact with ICsprout55 when synthesizing the running light project. Specifically, you can open the synthesized netlist file, and the cells instantiated in the netlist file are all standard cells of ICsprout55.

Content of the PDK

As mentioned above, the PDK contains a series of resources under a specific process node, such as device models, design rules, process constraints, verification files, and standard cell libraries. And the standard cell library is a collection of standard cells and their attributes, and these attributes include logical functions, transistor structures, timing, power consumption, physical dimensions, and other information. Usually, this information is distributed in various file formats in the PDK, and the .lib file mentioned above is just one of them. Taking ICsprout55 as an example, the files in it include (some files are not listed):

.
├── IP
│   ├── IO        # IO library
│   └── STD_cell  # Standard cell library
│       └── ics55_LLSC_H7C_V1p10C100   # Version number
│           ├── ics55_LLSC_H7CL        # LVT standard cells
│           │   ├── cdl
│           │   │   └── ics55_LLSC_H7CL.cdl        # Transistor-level information of standard cells
│           │   ├── cell_list
│           │   │   └── ics55_LLSC_H7CL.txt        # Name list of standard cells
│           │   ├── doc                            # Documentation of standard cells
│           │   ├── lef
│           │   │   └── ics55_LLSC_H7CL.lef        # Physical geometry information of standard cells
│           │   ├── liberty
│           │   │   └── ics55_LLSC_H7CL_typ_tt_1p2_25_nldm.lib   # Logical functions
│           │   │                                                # and PPA information of standard cells
│           │   └── verilog
│           │       └── ics55_LLSC_H7CL.v          # Verilog behavioral simulation models of standard cells
│           └── ics55_LLSC_H7CR
└── prtech
    └── techLEF
        └── N551P6M.lef    # Process-related design specifications

The above files are all text files and can be directly opened and read with a text editor.

As you can see, the name of the standard cell library currently open in ICsprout55 is ics55_LLSC_H7C_V1p10C100. Among them, ics55 is the abbreviation of ICsprout55, LLSC means Low Leakage Standard Cell, H7 indicates that the height of the standard cells is 7 tracks, C indicates the major version number (there were also major versions A and B before), and V1p10C100 indicates the specific minor version.

In the full flow of processor design, different design stages use different files. For example, the technology mapping stage of synthesis will read the .lib file and, according to the logical functions of standard cells, map logically equivalent subcircuits to the corresponding standard cells; when performing netlist simulation, the .v file is read to let the RTL simulator carry out standard cell-level simulation, thereby verifying that the function of the synthesized netlist meets expectations; when performing placement, the .lef file needs to be read, and the position of each standard cell is determined according to information such as the size of the standard cells.

Chip Structure from a Process Perspective

To facilitate everyone's understanding of the information in the PDK and the subsequent physical design stages, we first need to understand the structure of the chip from the perspective of the process. In semiconductor manufacturing, the physical structure of a chip is hierarchical. For example, the side view of a chip of a certain process is shown in the following figure:

--------------------     M7    ------ Power
  | | | | | | | | |
--------------------     M6    ------ Clock
  | | | | | | | | |
--------------------     M5    --+
  | | | | | | | | |             |
--------------------     M4      |
  | | | | | | | | |             +--- Wiring between standard cells
--------------------     M3      |
  | | | | | | | | |             |
--------------------     M2    --+
  | | | | | | | | |
--------------------     M1    ------ Wiring between transistors
  | | | | | | | | | <------- Via
=====================  Poly-silicon  --+
+++++++++++++++++++++  dielectric    +--- Transistors
ooooooooooooooooooooo  Silicon substrate  --+

Among them, the bottom layer is the silicon substrate, which contains the source and drain of the transistors; above it is the dielectric layer, also called the gate oxide layer, which usually uses silicon dioxide as the material; above that is the poly-silicon layer, which serves as the gate of the transistors. These three layers are used to realize the physical structure of the transistors.

Above the poly-silicon layer, there are multiple metal layers, which use their conductive properties to realize signal transmission, thereby connecting different transistors and realizing the functions of different gate circuits or standard cells. There are two ways of connection: intra-layer connection and cross-layer connection. The former routes within the same metal layer, and the latter connects through vias between different metal layers. The connection relationships between various components in the RTL logic design are physically realized through the connection function provided by the metal layers.

To distinguish different metal layers, they are usually numbered. The larger the number, the higher the layer. Different metal layers have different requirements for the width and spacing of the wires in them, and thus play different roles, as shown in the following table. It should be added that, according to the physics knowledge from middle school, the resistance of a wire is inversely proportional to its cross-sectional area.

Metal Layer	Wire Width	Wire Spacing	Wire Characteristics	Role
Lower	Small	Small	High resistance, short transmission distance, high wiring density	Connect different transistors to form gate circuits and standard cells
Middle	Medium	Medium	Medium resistance, medium transmission distance, medium wiring density	Connect different standard cells to realize the main logic of the chip
Higher	Large	Large	Low resistance, long transmission distance, low wiring density	Power

For different manufacturing processes, the number of metal layers may be different. For example, the process structure in the above figure is abbreviated as 1P7M, where P stands for Poly, that is, the poly-silicon layer; M stands for Metal, that is, the metal layer; therefore 1P7M indicates 1 poly-silicon layer and 7 metal layers. In 1P7M, M1 is the lower metal layer, M2-M6 are the middle metal layers, and M7 is the higher metal layer. It can be seen that in 1P7M, there are 5 middle metal layers specially used to realize connections between standard cells.

Among the signals connecting different standard cells, clock signals and data signals are different. Since the clock signal needs to connect a large number of flip-flops, its transmission distance is longer than that of ordinary data signals, so a larger wire width is usually adopted (for example, 2 times the wire width of data signals). Backend engineers will specify the parameters of the wire width in the EDA tool. At the same time, backend engineers will also specify which metal layer is used to realize the clock signal. Theoretically, any middle metal layer is possible, but habitually, the layer below the higher metal layer is chosen to realize the clock signal (such as M6 in the above example).

Usually, advanced processes provide more metal layers, such as 1P9M, 1P11M, etc. They can provide richer space for connections between standard cells, but more metal layer masks are needed in the manufacturing process, so the manufacturing cost is also higher.

The attributes of the metal layers are recorded in the process LEF file of the PDK. The LEF file has the suffix .lef and adopts the Library Exchange Format. It describes the physical layer information of the corresponding process, such as metal layers, vias, and layout rules, in text form.

vim icsprout55/prtech/techLEF/N551P6M.lef

For example, you can see the definition of LAYER MET1, and the related fields describe the attributes of the first metal layer.

LAYER MET1
  TYPE ROUTING ;
  DIRECTION HORIZONTAL ;
  PITCH 0.2 0.2 ;
  WIDTH 0.09 ;
  OFFSET 0.1 0.1 ;
  AREA 0.042 ;
  SPACING 0.09 ;
  MAXWIDTH 10 ;
  MINENCLOSEDAREA 0.18 ;
  CAPACITANCE CPERSQDIST 0.0007630 ;
  EDGECAPACITANCE 0.0000339 ;
  RESISTANCE RPERSQ 0.1122 ;
  DCCURRENTDENSITY AVERAGE 1.5 ;
END MET1

Among them, the TYPE field is ROUTING, indicating that this layer is used for routing; the WIDTH field and the PITCH field give the minimum wire width and the minimum wire spacing of this layer in units of respectively, as shown in the following figure. If you want to know more about LEF files, you can consult the relevant manualopen in new window.

 WIDTH
   |
 <-+->
|     |                          |     |
|     |                          |     |
|     |                          |     |
|     |                          |     |
|wire |                          |     |
|     |                          |     |
|     |                          |     |
|     |                          |     |
|     |                          |     |
|     |                          |     |
|     |           PITCH          |     |
|     |             |            |     |
|     |             |            |     |
|     |             |            |     |
   |<---------------+-------------->|

Before the definition of the metal layers, you should also be able to see the definition of the poly-silicon layer LAYER POLY, but it only has a TYPE field and no other fields. This is because the poly-silicon layer, together with the dielectric layer and the silicon substrate, is used to realize transistors, and the parameters of the transistors are determined by the process, which is relatively fixed for the backend physical design process, unlike the metal layers, which can let EDA tools dynamically route according to the design requirements. Therefore, in the LEF file, it is only necessary to declare its existence, and more process details are recorded in other files (such as GDS). Similarly, the dielectric layer and the silicon substrate are functionally tightly bound to the poly-silicon layer, and do not even need to appear in the LEF file.

Learn about the metal layers of ICsprout55

Read the process LEF file of ICsprout55. How many metal layers does it contain? And try to infer the role of each metal layer according to the wire width and wire spacing.

If the scale of a processor is complex (such as an out-of-order superscalar high-performance processor), there will be many wires between standard cells, which will put great pressure on the routing stage, and the wires will need to take detours. This not only increases the area of the chip, but also increases the net delay and lowers the frequency of the chip. It may also fail to route due to excessive congestion, making it impossible to manufacture a functionally correct chip. Therefore, the design of high-performance processors usually chooses processes with more metal layers, so as to relieve the pressure of the routing stage through richer routing space. For example, the Xiangshan processor team tried to switch the process from 1P9M to 1P11M during the design process, and without modifying the RTL code, the net delay could be reduced and the main frequency of the processor could be increased.

Processes with Multiple Poly-silicon Layers

Not all processes have only 1 poly-silicon layer. According to different application scenarios, processes with more poly-silicon layers may be adopted. For example, the memory cells of flash memory use floating-gate transistors, which are special transistors containing two gates. One of them is called the floating gate, which has two states of "storing charge" (charged) and "not storing charge" (discharged), representing 0 and 1 respectively; the other is called the control gate, which is used to control the read and write of the memory cell. Flash memory adopts the 2P8M manufacturing process to realize this special transistor, in which the two poly-silicon layers are respectively used to realize the floating gate and the control gate.

Attributes of Standard Cells

The standard cell library provided by the PDK usually contains many standard cells. To make it convenient to know the attributes of standard cells, the naming of standard cells usually follows certain conventions. In ICsprout55, the naming of standard cells follows the convention of function + drive strength + H + number of tracks + threshold voltage. For example, NAND2X1H7L indicates that the function of this standard cell is a 2-input NAND gate, the drive strength is X1, that is, 1 time the standard drive strength, its height is 7 tracks, and the threshold voltage is LVT; OR3X0P5H7R indicates that the function of this standard cell is a 3-input OR gate, the drive strength is X0P5, that is, 0.5 times the standard drive strength (P indicates the decimal point), its height is 7 tracks, and the threshold voltage is RVT. Next, we will take NAND2X1H7L as an example and consult the related files in the standard cell library to further understand the various attributes of standard cells.

LIB Files - Function, Timing, and Power Consumption

LIB files have the suffix .lib and adopt the Liberty Timing File format. They describe the function of standard cells, as well as attributes such as timing and power consumption under certain conditions, in text form.

cd icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/
vim ics55_LLSC_H7CL/liberty/ics55_LLSC_H7CL_typ_tt_1p2_25_nldm.lib

After a simple consultation, we find that a LIB file consists of some header fields and the descriptions of several standard cells (cell). For example, we can directly search for NAND2X1H7L to consult the related attributes of this standard cell.

  cell (NAND2X1H7L) {
    area : 1.12;
    cell_footprint : "NAND2X1H7L";
    cell_leakage_power : 0.434974;
    pg_pin (VDD) {
      pg_type : primary_power;
      voltage_name : "VDD";
    }
    pg_pin (VSS) {
      pg_type : primary_ground;
      voltage_name : "VSS";
    }
    leakage_power () {
      value : 0.312371;
      when : "(A * B * !Y)";
      related_pg_pin : VDD;
    }
    leakage_power () {
      value : 0;
      when : "(A * B * !Y)";
      related_pg_pin : VSS;
    }
    leakage_power () {
      value : 0.82883;
      when : "(A * !B * Y)";
      related_pg_pin : VDD;
    }
    leakage_power () {
      value : 0;
      when : "(A * !B * Y)";
      related_pg_pin : VSS;
    }
    leakage_power () {
      value : 0.565379;
      when : "(!A * B * Y)";
      related_pg_pin : VDD;
    }
    leakage_power () {
      value : 0;
      when : "(!A * B * Y)";
      related_pg_pin : VSS;
    }
    leakage_power () {
      value : 0.0333159;
      when : "(!A * !B * Y)";
      related_pg_pin : VDD;
    }
    leakage_power () {
      value : 0;
      when : "(!A * !B * Y)";
      related_pg_pin : VSS;
    }
    leakage_power () {
      value : 0.434974;
      related_pg_pin : VDD;
    }
    leakage_power () {
      value : 0;
      related_pg_pin : VSS;
    }
    pin (Y) {
      direction : output;
      function : "(!A) + (!B)";
      output_voltage : default_VDD_VSS_output;
      power_down_function : "(!VDD) + (VSS)";
      related_ground_pin : VSS;
      related_power_pin : VDD;
      max_capacitance : 0.055;
      timing () { ......  }
      timing () { ......  }
      internal_power () { ...... }
      internal_power () { ...... }
      internal_power () { ...... }
      internal_power () { ...... }
    }
    pin (A) {
      direction : input;
      driver_waveform_fall : "PreDriver20.5:fall";
      driver_waveform_rise : "PreDriver20.5:rise";
      input_voltage : default_VDD_VSS_input;
      related_ground_pin : VSS;
      related_power_pin : VDD;
      max_transition : 0.795659;
      capacitance : 0.000898206;
      rise_capacitance : 0.000898206;
      rise_capacitance_range (0.000705173, 0.000898206);
      fall_capacitance : 0.000888785;
      fall_capacitance_range (0.000696354, 0.000888785);
      internal_power () { ...... }
      internal_power () { ...... }
    }
    pin (B) {
      direction : input;
      driver_waveform_fall : "PreDriver20.5:fall";
      driver_waveform_rise : "PreDriver20.5:rise";
      input_voltage : default_VDD_VSS_input;
      related_ground_pin : VSS;
      related_power_pin : VDD;
      max_transition : 0.795659;
      capacitance : 0.000953054;
      rise_capacitance : 0.000953054;
      rise_capacitance_range (0.000589512, 0.000953054);
      fall_capacitance : 0.000952783;
      fall_capacitance_range (0.000588209, 0.000952783);
      internal_power () { ...... }
      internal_power () { ...... }
    }
  }

So far, the attributes we can understand include (the units of some attributes are defined in the header fields):

Area (area), generally in units of
Leakage power (leakage power), which includes the leakage power of the standard cell under various conditions
Internal power (internal power), which includes the internal power of the standard cell under various conditions
Pins (pin), including direction (direction), capacitance (capacitance), etc.; in particular, for output pins, the following information is also included
- Function (function), given by a logical expression, from which we can understand the function of the standard cell
- Timing (timing), which includes the delay of the standard cell under various conditions

Let us explain a little about the meaning of the area attribute. A chip is a three-dimensional object, and the standard cells in the chip also exist in three-dimensional space. For the convenience of description, we assume that the chip is placed horizontally and a three-dimensional coordinate system is established. The area of a standard cell refers to the area of its projection on the plane, that is, the area in the top view. Considering the process structure of the chip, the area of a standard cell is also the area it occupies in the poly-silicon layer and the lower metal layers.

From the above attributes, it can be seen that LIB files are mainly used for synthesis, timing analysis, and power consumption analysis. For example, yosys will read the LIB file when performing technology mapping, and according to the function field of the standard cells, decide which subcircuits are mapped to which standard cells, so as to ensure that the circuit logic described by the netlist is equivalent to the input RTL code; the iSTA tool will calculate the logic delay of each standard cell under various conditions according to the timing field of the standard cells, and finally report several longest paths of the netlist.

RTFM

The above LIB file has millions of lines, which is inconvenient to consult directly. We recommend that you consult the related standard cell data book, which is located at icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/ics55_LLSC_H7CL/doc/ics55_LLSC_H7CL_TYPICAL_V1P2_T25.pdf.

If you want to understand the specific meanings of each field in the LIB file, you can consult the file format manual of Liberty Timing Fileopen in new window.

Verilog Files - Behavioral Models

To verify that the synthesized netlist is equivalent to the RTL design before synthesis, one way is to perform netlist simulation, that is, to simulate the netlist in combination with the behavior of the standard cells. Although the function field of the standard cells in the LIB file also describes the behavior of the standard cells, RTL simulators usually cannot recognize LIB files. Therefore, the standard cell library usually also provides Verilog behavioral models of the standard cells.

In ICsprout55, the Verilog behavioral models of the standard cells are located in the following file:

cd icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/
vim ics55_LLSC_H7CL/verilog/ics55_LLSC_H7CL.v

For example, the behavioral model of NAND2X1H7L is as follows:

module NAND2X1H7L (Y, A, B);
output Y;
input A, B;

  nand (Y, A, B);

endmodule //NAND2X1H7L

As you can see, this is just using the Verilog language to implement the function of the standard cell once. Here, the built-in primitive nand of the Verilog language is used to implement the function of the 2-input NAND gate. Input the netlist file together with this behavioral model file into the RTL simulator, and the RTL simulator will instantiate the standard cells in the netlist file according to the module definitions in the model file, thereby carrying out the simulation work at the netlist level.

The behavioral models provided by ICsprout55 can not only be used for functional simulation, but also contain rich timing information (given by specify statements), which can support users in carrying out timing simulation work at the netlist level.

LEF Files - Physical Geometry Information

We have already introduced the process-related LEF files above. In fact, there is also a type of LEF file related to standard cells, which is used to describe the physical geometry information of standard cells.

cd icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/
vim ics55_LLSC_H7CL/lef/ics55_LLSC_H7CL.lef

Taking NAND2X1H7L as an example, its description in the LEF file is as follows:

MACRO NAND2X1H7L
  CLASS CORE ;
  ORIGIN 0 0 ;
  FOREIGN NAND2X1H7L 0 0 ;
  SIZE 0.8 BY 1.4 ;
  SYMMETRY X Y ;
  SITE core7 ;
  PIN A
    DIRECTION INPUT ;
    USE SIGNAL ;
    PORT
      LAYER MET1 ;
        RECT 0.055 0.425 0.23 0.59 ;
    END
  END A
  ......
END NAND2X1H7L

Among them, SYMMETRY X Y indicates that the standard cell can be placed symmetrically along the -axis or the -axis, so as to optimize the effect of the placement (such as the net delay to a certain port, etc.); the PIN field is used to describe some attributes of the specified pin, including the direction (DIRECTION) and the geometry of the port (PORT), etc. The PORT further describes that the port needs to occupy a rectangle on the MET1 layer, and the shape is given by the RECT field.

SITE gives the alignment rule that needs to be followed when placing the standard cell. Here, the value core7 of this field indicates that it references an alignment rule defined elsewhere, specifically located in the process LEF file:

SITE core7
    SIZE 0.200 BY 1.400 ;
    CLASS CORE ;
    SYMMETRY Y  ;
END core7

Here, SYMMETRY Y means that the standard cell can be placed symmetrically along the -axis; SIZE 0.200 BY 1.400 gives the alignment rule as 0.2 X 1.4, that is, when placing a standard cell, the -axis coordinate must be an integer multiple of 0.2, and the -axis coordinate must be an integer multiple of 1.4. Looking back at the SIZE field of NAND2X1H7L, it gives the dimensions of the standard cell. As you can see, the length 0.8 on the -axis and the length 1.4 on the -axis in the SIZE field are respectively integer multiples of 0.2 and 1.4 in the alignment rule. More generally, it can be considered that SITE defines a grid cell, and from the perspective of size, all standard cells are rectangles composed of one or more grid cells.

As you can see, the LEF file describes the geometry information of the standard cell in detail. This information will help EDA tools place the standard cells correctly in the chip.

CDL Files - Transistor Structure Description

CDL files have the suffix .cdl. They are actually based on a circuit description language (Circuit Description Language), which describes the transistor structure of standard cells in text form.

cd icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/
vim ics55_LLSC_H7CL/cdl/ics55_LLSC_H7CL.cdl

The format for describing the transistor structure in a CDL file is as follows:

.SUBCKT subcircuit name port1 port2 ...
transistor instance name drain gate source substrate transistor type channel width channel length
...
.ENDS

Taking NAND2X1H7L as an example, its description in the CDL file is as follows:

.SUBCKT NAND2X1H7L A B VDD VSS Y
*.PININFO A:I B:I Y:O VDD:B VSS:B
MMN0 Y B net6 VSS nm1p2_lvt_lp W=210n L=60n m=1
MMN1 net6 A VSS VSS nm1p2_lvt_lp W=210n L=60n m=1
MMP1 Y B VDD VDD pm1p2_lvt_lp W=270n L=60n m=1
MMP0 Y A VDD VDD pm1p2_lvt_lp W=270n L=60n m=1
.ENDS

Among them, the lines starting with * are comments. The above description defines a subcircuit (i.e., a standard cell) named NAND2X1H7L through .SUBCKT, which has 5 ports, in order A, B, VDD, VSS, and Y. The line starting with MMN0 instantiates an nMOS transistor named MMN0, whose drain is connected to the port Y, gate to the port B, source to the net net6, and substrate to the port VSS; the transistor type adopted is nm1p2_lvt_lp, and the width and length of the channel are respectively and . The remaining content of the above example describes the remaining transistors and their connection relationships in a similar way.

Draw the transistor structure according to the CDL file

Try to draw the transistor structure of the standard cell NAND2X1H7L according to the above CDL description, and check whether its function is consistent with that of a NAND gate.

The transistor structure information described in the CDL is mainly used for transistor-level SPICE simulation, and for checking the consistency between the GDS layout and the netlist logic. The latter work is called LVS (Layout Versus Schematic).

GDS Files - Physical Layout

GDS files have the suffix .gds and contain all the physical and process information needed to manufacture a standard cell. GDS files are not text files and need specialized tools to parse and read them. The GDS files of ICsprout55 are not open yet. However, "One Student One Chip" does not impose requirements on the specific content in GDS files, so we will not elaborate here.

Classification of Standard Cells

There are many kinds of standard cells in a standard cell library. They can be classified according to their functions, including but not limited to the following categories. Generally speaking, the first 5 categories of cells and clock buffers are necessary, so as to ensure that the basic functions of various designs can be correctly implemented. By providing other types of cells, users can design better circuits for specified scenarios, or realize more convenient chip debugging functions.

Logic Gate Cells

Logic gate cells include basic logic gates (AND gates, OR gates, NOT gates, etc.) and complex logic gates.

Understand the Function of Complex Logic Gate Cells

In the LIB file of ICsprout55, there are also standard cells named like OAI22X1H7L, whose functions are not intuitive. Try to consult the related attributes of the standard cell OAI22X1H7L to understand its function.

After consulting the LIB file of ICsprout55, it can be found that the function of the standard cell OAI22X1H7L is more complex than that of a single logic gate. According to De Morgan's laws, the logical expression of the output port of OAI22X1H7L can be transformed:

(!A0 * !A1) + (!B0 * !B1) = !(A0 + A1) + !(B0 + B1) = !((A0 + A1) * (B0 + B1))

Here + represents the OR operation, * represents the AND operation, and ! represents the NOT operation. As you can see, the function of this standard cell includes two 2-input OR gates, one 2-input AND gate, and one NOT gate. This type of logic gate is called a complex gate. If we consult the area of the related standard cells, we can get the following data:

area(OAI22X1H7L) = 1.96
area(OR2X1H7L)*2 + area(AND2X1H7L) + area(INVX1H7L) = 1.68*2 + 1.68 + 0.84 = 5.88

As you can see, the area of the standard cell OAI22X1H7L is much smaller than the area spent by using multiple functionally equivalent logic gate cells. This is because realizing the logical functions of "AND" and "OR" through the series and parallel connection of transistors is much less costly than realizing the corresponding logical functions through "AND gates" and "OR gates". The cost here is not only reflected in the area, but also in the delay and power consumption. Therefore, the standard cell library does not only contain simple logic gate cells. For complex logic gates like OAI22X1H7L implemented at the transistor level, they are also provided as standard cells, so that the chip can have better PPA.

Understand the Transistor Structure of OAI22

Consult the transistor structure of OAI22X1H7L in the CDL file. How many transistors does it have? Try to understand how its transistor structure implements the logical expression of OAI22X1H7L.

The Naming of OAI22

In fact, the naming of OAI22 has its meaning, where OAI stands for Or-And-Invert, and 22 indicates two groups of input signals, with two in each group. Let us assume the input signals are A0, A1, B0, B1 respectively. Then, OAI means first performing the Or operation within each group of signals to get A0 | A1 and B0 | B1; then performing the And operation on the results to get (A0 | A1) & (B0 | B1); and finally performing the Invert operation on the result to get !((A0 | A1) & (B0 | B1)).

Understand the Function of Complex Logic Gate Cells (2)

Similarly, there is a standard cell named AOI221. Try to list its logical expression according to the naming, and consult the function in the standard cell library to compare whether your understanding is correct.

The suffixes like X1, X4, etc. contained in standard cells indicate the drive strength of the standard cell. Drive strength refers to the current that a standard cell can source or sink while maintaining a specified voltage range, and it affects the time required for the downstream standard cells to flip. Therefore, NAND2X1H7L, NAND2X2H7L, and NAND2X4H7L are completely equivalent in logical function, but NAND2X4H7L can provide greater drive strength, enabling its downstream logic to flip faster. However, this requires larger or more transistors to implement, so NAND2X4H7L has a larger area and higher power consumption.

Understand Drive Strength

Try to consult the related attributes of NAND2X1H7L, NAND2X2H7L, and NAND2X4H7L, and compare their areas and power consumptions.

Understand Drive Strength (2)

Try to consult the transistor structure of NAND2X2H7L. Compared with NAND2X1H7L, what is the difference?

Considering the trade-offs of different drive strengths in terms of performance, area, power consumption, and other indicators, standard cells with higher drive strengths are usually used on the critical paths that affect the frequency, so as to reduce the delay of the critical paths and improve the frequency of the chip; standard cells with lower drive strengths are used on the non-critical paths that do not affect the frequency, so as to reduce the overall area and power consumption of the chip without lowering the frequency of the chip.

Sequential Cells

Sequential cells include flip-flops, latches, and so on, among which there are various types with or without clear/set terminals, such as the flip-flop DFFX1H7L and so on.

Draw the Transistor Structure According to the CDL File (2)

Consult the transistor structure of DFFX1H7L in the CDL file. Among them, TSINV is a tristate inverter, and its transistor structure can refer to the structure of the .SUBCKT TSINV subcircuit. Draw the transistor structure of DFFX1H7L according to the description of the CDL file. How many transistors does this standard cell consist of? And try to understand how the flip-flop function is realized through this transistor structure.

I/O Cells

A chip needs to communicate with the outside world through I/O cells (input/output cells). I/O cells are used to connect the internal I/O signals of the chip with the metal bonding pads. After the chip is produced, the packaging process will lead out metal pins from the metal bonding pads of the I/O cells, thereby allowing the external signals of the chip to interact with the internal I/O signals of the chip through the pins.

The I/O cells of ICsprout55 can be referenced from the related LIB file:

cd icsprout55/IP/IO/ICsprout_55LLULP1233_IO_251013/
vim liberty/ICSIOA_N55_3P3_tt_1p2_3p3_25c.lib

Among them, I/O cells can be further classified as follows:

Data I/O cells (also called GPIO), used to provide the input and output of data signals, such as P65_1233_PBMUX.
Core power cells, used to provide power for the transistors inside the chip, including the source power (VSS) and the drain power (VDD), such as P65_1233_VSS1 and P65_1233_VDD1.
I/O power cells, used to provide power for the data I/O cells (i.e., the first type of I/O cells), such as P65_1233_VSSIO3 and P65_1233_VDDIO3. Data I/O cells are usually more complex than general standard cells, so their power supply requirements are also different from those of general standard cells. Therefore, core power cells (i.e., the second type of I/O cells) cannot be used to supply power to the data I/O cells.

Although I/O cells are also part of the standard cell library, their areas are several orders of magnitude larger than those of general standard cells. This is because communicating with the outside world of the chip puts more requirements on the functions of I/O cells, for example, they need to have strong drive strength to send signals to the outside of the chip, need to integrate protection circuits to prevent external static electricity from damaging the inside of the chip, and need to conform to the physical dimensions and soldering requirements of the chip pins (such as spacing, metal layer thickness, reserving blank areas to avoid short circuits), and so on. Therefore, the circuit-level implementation of I/O cells is much more complex than that of general standard cells.

Learn About the Size of I/O Cells

Try to consult the related files in ICsprout55 to learn the size of a 2-input NAND gate and the size of an I/O cell, and compare them.

Driver Cells

Driver cells are used to enhance the drive strength of signals, ensure signal integrity, and optimize timing and load. When a signal is transmitted over too long a distance or has too many downstream circuits (high fan-out), the signal may have too high a transmission delay due to insufficient drive strength, and may even be distorted, leading to errors. Inserting driver cells helps alleviate the above problems. They are specifically divided into:

Logical non-inverting driver cells, also called buffers, whose outputs are logically identical to their inputs. In ICsprout55, such driver cells include BUFX1H7L, BUFX2H7L, BUFX4H7L, etc. The larger the number after X, the stronger the drive strength of the cell.
Logical inverting driver cells, also called inverters, whose functions are the same as NOT gates, and also come in various drive strengths.

Physical Cells

Physical cells themselves have no logical functions and are mainly used to solve specific problems in backend physical design that are unrelated to the circuit's logical functions. Some common physical cells include:

Pull-up/pull-down cells. Such cells have no inputs, only outputs, and respectively provide the functions of logic 0 (low level) and logic 1 (high level). In ICsprout55, the pull-up cell and the pull-down cell are respectively TIELOH7L and TIEHIH7L.
Filler cells. They are used to fill the blank areas in the chip to ensure the continuity of certain layers (such as the power layer) and avoid defects caused by the manufacturing process. In ICsprout55, filler cells include FILLER1H7L, FILLER2H7L, etc.
Decoupling cells (decap). They are used to avoid the impact of the dynamic voltage drop caused by the simultaneous flipping of a large number of cells in the circuit. In ICsprout55, decoupling cells include FILLCAP4H7L, FILLCAP8H7L, etc.
Antenna effect repair cells. In the ion etching step of the chip manufacturing process, under certain conditions, the antenna effect may be triggered in the circuit, and this effect will break down the transistors, making them ineffective. Adding this kind of standard cells at appropriate positions can eliminate the antenna effect, thereby ensuring the correctness of the chip. In ICsprout55, the antenna effect repair cells include ANT2H7L and ANT4H7L.

Macro Cells

Macro cells are standard cells with specific functions whose physical implementations are pre-designed by the vendors (wafer fabs or IP vendors) and have relatively large areas, such as SRAM memories, DDR phy modules, etc. SRAM memories are a common type of macro cells and are often used in processor design. ICsprout55 has not opened the related macro cells yet.

Complex Function Units

Complex function units include multiplexers, half-adders, full-adders, comparators, etc. Compared with building functionally equivalent circuits with logic gates, providing these functions as standard cells can achieve better PPA. In ICsprout55, complex function units include MUX2X1H7L, MUXI2X1H7L, ADDHX1H7L, ADDFX1H7L, etc.

Full-Custom Circuits of Complex Cells

Taking ADDHX1H7L as an example, try to find the area and transistor structure of this standard cell from the related files of the standard cell library. Suppose a certain standard cell library does not provide a half-adder standard cell and a half-adder needs to be built with several standard cells of basic logic gates. Please calculate the area and the number of transistors required in this case.

Clock-Specific Cells

Clock-specific cells are cells specially used to process clock signals, including clock buffers, clock gating cells, logic gate cells used to process clock signals, and so on. The reason why general standard cells (such as AND gates, buffers, etc.) cannot be used to process clock signals is the particularity of clock signals:

A subtle change in the clock signal may cause flip-flops to fail to work correctly. For example, a glitch in the clock signal caused by jitter may be mistaken by a flip-flop as the arrival of a clock edge.
The delay of the clock signal will affect the timing of flip-flops, and further affect the working frequency of the entire circuit.
All flip-flops in the circuit need to be connected to the clock, so the fan-out of the clock signal is very large and the transmission distance is very long, requiring strong drive strength. According to the introduction of the internal structure of the chip above, the clock signal usually adopts a larger wire width.

Therefore, compared with general standard cells, the designers of the standard cell library need to design clock-specific cells in a targeted way, so that they have characteristics such as low jitter, low delay, and high drive strength.

In ICsprout55, clock-specific cells include ICGX1H7L, ICGNX1H7L, etc.

Power Management Cells

Power management cells are used to realize low-power designs, including power gating cells, isolation cells, etc. ICsprout55 has not opened such cells yet.

Test and Debug Cells

Test and debug cells are used to support the testing and debugging of chips after manufacturing, including scan chain cells, Built-In Self Test (BIST) control cells, and so on.

Scan chain cells are usually used in Design for Testability (DFT). On the basis of general flip-flops, they add a scan enable terminal SE (scan enable) and a scan input terminal SI (scan input). When SE is active, SI is used to update the flip-flop. Therefore, developers can inject specific states into such flip-flops through external control, thereby helping developers debug the manufactured chip. However, compared with general flip-flops, scan chain cells have larger areas and higher power consumption.

In ICsprout55, test and debug cells include SDFFX1H7L, SDFFSX1H7L, SDFFRX1H7L, etc.

Learn About All the Standard Cells

Try to further understand the standard cells provided by ICsprout55 in combination with the related files of the PDK. You can check the corresponding comments and functional attributes to understand the roles of the related standard cells. After understanding them, you will have a simple understanding of how your RTL code is processed by the synthesizer.

PVT Corners

The delay of a circuit is mainly affected by three factors: process (Process), voltage (Voltage), and temperature (Temperature). The three are collectively called PVT parameters. Backend engineers generally select multiple combinations of PVT parameters as a series of environments, and try their best to ensure that the chip can work in these environments in the future during the design stage. These environments are called PVT corners.

In the standard cell library, different PVT corners are reflected as different LIB files. In these LIB files, the names and areas of the standard cells are the same, but the delays and power consumptions are different. By carrying out evaluations with different LIB files, backend engineers can understand whether the chip can work as expected under the corresponding PVT corner.

Process variation refers to the uncontrollable disturbance factors in the chip manufacturing process. For example, the environment of the chips at the center of a wafer is different from that of the chips at the edge of the wafer; the thickness of the transistor metal layer is not completely uniform; the doping concentration of the transistor substrate is not uniform, and so on. These factors all affect the resistance and capacitance of the transistors, and ultimately affect the delay performance of the transistors: they may become faster, and may also become slower.

To test that the circuit can work correctly under various transistor delays, several cases are generally defined according to the working speed of the transistors, and these cases are called process corners. Process corners are usually named with two letters. The first letter indicates the working speed of nMOS, and the second letter indicates the working speed of pMOS. The working speed is divided into three cases: typical (denoted by the letter t), fast (denoted by the letter f), and slow (denoted by the letter s). Among them, fast and slow are both relative to the typical case. Therefore, according to the polarity and the working speed of the transistors, five process corners can be combined: ss, tt, ff, sf, and fs. For example, fs indicates the delay case where nMOS works faster than the typical case, but pMOS works slower than the typical case.

     pMOS
      ^
      |     sf            ff
 fast +    o-------------o
      |    |             |
      |    |       tt    |
      |    |      o      |
      |    |             |
      |    |ss           |fs
 slow +    o-------------o
      |
      +----+-------------+---> nMOS
          slow          fast

Is "tt" a "corner"?

In a coordinate axis, if the X-axis represents the working speed of nMOS and the Y-axis represents the working speed of pMOS, then ss, ff, sf, and fs will respectively fall at the four corners of a rectangle, which is also the origin of the term "process corner". And tt actually falls at the center of the rectangle. Strictly speaking, it is not a "corner". But as a typical case, backend engineers still classify it into the concept of "process corner".

Among the above five process corners, for ss, tt, and ff, the working speeds of nMOS and pMOS are basically consistent, so they do not have much impact on the overall function of the transistors, but only affect their delays. But for sf and fs, since one of nMOS and pMOS becomes faster while the other becomes slower, the delay of the CMOS as a whole changing from 0 to 1 is different from that from 1 to 0. To ensure that various circuit elements can work correctly, the determination of element delay parameters needs to be more cautious. However, in the actual manufacturing process, since process variation also has a certain randomness, the probability that the working speeds of nMOS and pMOS in a chip happen to change in opposite directions is very low. Therefore, backend engineers usually do not consider the two process corners sf and fs, and ICsprout55 also does not provide the LIB files corresponding to sf and fs.

Process Corners and Intel Processor Models

Due to the existence of process variation, chips of the same batch may have different performance. Intel just makes use of this: it classifies the chips belonging to different process corners in the same batch into different levels of models for sale. For example, in the Intel Core series, most chips whose performance belongs to the tt process corner are sold under the i5 model; a small number of chips belonging to the ff process corner can run at higher frequencies, and are sold under the more expensive i7 model to earn more profit; while the remaining chips belonging to the ss process corner can only run at lower frequencies than tt, and are sold under the cheaper i3 model, avoiding discarding them as defective chips.

In the working environment of a chip, the voltage is also not constant. For example, the current passing through the power supply network will form a voltage drop according to its resistance, so that the input voltages of the standard cells at different positions are not completely the same: the standard cells close to the power I/O cells can obtain stronger input voltages, and the transistors work faster; while the standard cells far from the power I/O cells, due to the existence of the voltage drop, relatively obtain lower input voltages, and the working speed of the transistors is also relatively slower. In addition, the power supply may also have white noise. Even for the standard cells at the same position, the working speed of the transistors will fluctuate with time. To cope with the fluctuation of voltage, backend engineers generally need to ensure that the circuit can work correctly within the interval of the standard working voltage (i.e., ).

Temperature also affects the working speed of transistors. On one hand, it is affected by the external ambient temperature. Some chips work in the high-temperature environment of factory workshops, and some chips work in the low-temperature environment of the North and South Poles. On the other hand, even if the external environment is the same, the transistors at different positions in the chip are affected by different temperatures: in the areas with high transistor density or high transistor flipping frequency, the generated heat is also high. Compared with normal temperature, an increase in temperature will slow down the working speed of transistors. This is because, according to the thermodynamic effect, particles have higher energy at high temperatures, so the atoms in the semiconductor material will vibrate more intensely in the crystal lattice. Affected by this vibration, the moving direction of the electrons in the transistor channel will be changed, thereby reducing the current, and further reducing the working speed of the transistors. Therefore, to improve the robustness of the chip, the working situations at different temperatures need to be considered.

The naming of LIB files usually contains the information of PVT corners. For example, ss_1p08_125 indicates a process corner of ss, a voltage of 1.08V, and a temperature of 125 degrees Celsius; ff_1p32_m40 indicates a process corner of ff, a voltage of 1.32V, and a temperature of -40 degrees Celsius. In the field of integrated circuits, naming methods like 1p08 that use p (representing point) to replace the decimal point . are very common. On one hand, some early file systems or EDA tools do not support decimal points in file names; on the other hand, in densely written technical documents or on boards with very small fonts, the visual distinction of 1p60 is better than that of 1.60, especially since the decimal point is easy to be overlooked. Using the letter m (representing minus) to replace the minus sign - is for similar considerations. In addition, different vendors may adopt different naming conventions, including using units (such as the letter v) to replace the decimal point (such as using 1v08 to represent 1.08V), using the letter n (representing negative) to replace the minus sign (such as using n40 to represent -40 degrees Celsius), and so on.

Try the Evaluation Results of Different PVT Corners

ICsprout55 provides LIB files for different PVT corners (located in the icsprout55/IP/STD_cell/ics55_LLSC_H7C_V1p10C100/ics55_LLSC_H7CL/liberty directory). > Try modifying the ecc.toml file read by ECC and replacing the LIB files with those corresponding to different PVT corners, then re-evaluate the performance of the circuit and compare the evaluation results under different PVT corners.

Since PVT corners describe the working situations of standard cells in different environments, the internal structures and geometry of the same standard cell are exactly the same under different PVT corners. Therefore, it is only necessary to include the timing information and power consumption information of different PVT corners in different LIB files. Using EDA tools to evaluate a chip under a certain PVT corner is actually answering the question "if the chip works in the future in the environment described by this PVT corner, what will its performance be like?". And the measured performance of the chip is related to its real working environment. If the actual working environment is inconsistent with the PVT corner adopted when designing the chip, the information reported by the EDA tools cannot fully represent the measured performance of the chip.

PVT Corners and Overclocking

A certain group of enthusiasts use techniques such as water cooling or even liquid nitrogen to overclock processors, successfully making computers run stably at higher working frequencies. Try to analyze, from the perspective of PVT corners, why these techniques can successfully overclock.

Vendors' Marketing Strategies

Some vendors may make use of the difference between PVT corners and the actual working environment for marketing. For example, a vendor adopts the PVT corner ff_1p32_m40 in the chip design stage, and the EDA tools report that the chip can run at a maximum frequency of 2GHz, so the vendor claims that its chip frequency reaches 2GHz. But after users purchase the vendor's chip or related products equipped with this chip, they find that the chip can only run at a maximum of 1.5GHz.

On one hand, users use chip products in a normal temperature (about 25 degrees Celsius) environment, not -40 degrees Celsius; on the other hand, in a batch of chips, the chips whose process variation is at the typical case account for the majority, and most users purchase these chips, while the chips whose process variation falls in the ff range account for the minority. If the vendor adopts the PVT corner tt_1p2_25 in the design stage, the data reported by the EDA tools will be closer to the actual usage situation of the users.

Therefore, if the frequency in a vendor's advertisement is not measured data, it is also necessary to pay attention to under which PVT corner the related data is evaluated, so as to make a more objective estimate of the future working situation of the chip.

Threshold Voltage

Recall the working principle of a transistor: the difference between the gate voltage and the source voltage must reach a certain threshold for the transistor to conduct; otherwise, the transistor is cut off. For transistors with different thresholds, their electrical attributes are different, so standard cells built with transistors of different thresholds also have different characteristics.

Standard cells with different threshold voltages are mainly used to strike a trade-off between delay and static power consumption. Specifically, for standard cells with a higher threshold voltage, it takes more time for the transistor to change from the cut-off state to the conducting state, so the delay is higher. As for static power consumption, as mentioned above, it is mainly produced by leakage current. In the current CMOS technology, the part accounting for the largest proportion of the leakage current is the sub-threshold current. The reason for the existence of the sub-threshold current is that when a transistor changes from the conducting state to the cut-off state, it does not instantly enter a perfect cut-off state, but enters a "sub-threshold" state. In this state, there is still a weak electric field near the gate, which still attracts a small number of electrons under its action. Although these electrons are not enough to form a channel connecting the source and the drain, they still produce a tiny current from the drain to the source, and this is the sub-threshold current. If other factors remain unchanged, the relationship between the sub-threshold current and the threshold voltage is as follows:

where and are two factors independent of . Since the sub-threshold current accounts for a relatively large proportion of the leakage current, the static power consumption can be approximately regarded as:

where is the supply voltage. As you can see, the higher the threshold voltage, the lower the leakage current and the lower the static power consumption. On the contrary, when the threshold voltage decreases, the static power consumption increases exponentially.

However, for standard cells with the same logical function but different threshold voltages, their areas are usually the same. This is because different threshold voltages are realized by adjusting the parameters of the transistors themselves, such as the doping concentration of the substrate and the thickness of the gate dielectric layer. These parameter adjustments do not affect the sizes and arrangements of the transistors in the standard cell, so they do not affect the area of the standard cell.

Standard cells are usually classified into the following categories according to the threshold voltage: HVT (High Voltage Threshold), RVT (Regular Voltage Threshold), LVT (Low Voltage Threshold), and ULVT (Ultra-Low Voltage Threshold). Among them, HVT has the highest threshold voltage, the lowest static power consumption, but the highest delay; ULVT is the opposite, with the lowest threshold voltage and delay, but the highest static power consumption. Some vendors call RVT "SVT" (Standard Voltage Threshold). Some process nodes also provide UHVT (Ultra-High Voltage Threshold) standard cells for users to choose. ICsprout55 provides standard cells of three different threshold voltages: HVT, RVT, and LVT.

Try Different Threshold Voltages

todo

Backend engineers need to select standard cells with appropriate threshold voltages to design chips according to the application scenarios of the chips. For example, in low-power application scenarios, HVT is preferred; in high-performance application scenarios, LVT or even ULVT is preferred. In occasions where both goals are pursued, a hybrid design approach can be chosen, that is, using LVT or ULVT on the critical paths that affect the frequency, so as to reduce the delay of the critical paths and improve the frequency of the chip; using RVT or HVT on the non-critical paths that do not affect the frequency, so as to reduce the overall static power consumption of the chip without lowering the frequency of the chip. For example, according to the "Xiangshan" paper published at MICRO, a top international conference in the field of computer architectureopen in new window, the proportions of standard cells with different threshold voltages in the first-generation "Xiangshan" processor chip are: ULVT 1.04%, LVT 19.32%, SVT 25.19%, HVT 53.67%.

Number of Tracks

The number of tracks is one of the attributes of standard cells, and it is another measure of the height of standard cells. The "height" here is not the measure of the projection of the standard cell on the -axis in three-dimensional space, but the measure of the projection on the -axis; correspondingly, the measure of the projection of the standard cell on the -axis is called the "width". Therefore, the terminology of the backend design in size description is different from the usage habit of geometric measurement concepts. The "width", "height", and "thickness" in the backend design respectively correspond to the "length", "width", and "height" in three-dimensional geometric space.

We already know that the PITCH attribute of a metal layer describes the minimum wire spacing of this layer. To make it convenient for EDA tools to carry out placement and routing work, the height of standard cells is usually made an integer multiple of the PITCH attribute, and this multiple is the number of tracks of the standard cell. There are many metal layers, but standard cells certainly use the M1 metal layer, so the PITCH attribute of the M1 metal layer is usually used as the reference for calculating the number of tracks.

In a standard cell library, the heights of the standard cells are usually the same, thereby further making it convenient for EDA tools to carry out placement work. Therefore, the standard cells of different standard cell libraries can also be described from the perspective of the number of tracks. For example, if the number of tracks of the standard cells in a certain standard cell library is 6, it is called "6T standard cells".

Understand the Number of Tracks of ICsprout55

It was already mentioned when introducing ICsprout55 above what its number of tracks is. Try to find the required parameters in the related files, calculate the number of tracks of the ICsprout55 standard cells, and check whether the calculated number of tracks is consistent with the number of tracks introduced above.

Standard cells with a smaller number of tracks (such as 6T, 7T) have smaller areas and lower power consumption, but weaker drive strength, which makes the transistors flip slowly, so the performance is not high; on the contrary, standard cells with a larger number of tracks (such as 12T, 13T) have higher performance, but larger areas and higher power consumption; there are also standard cells with a number of tracks in between (such as 9T, 10T), which are relatively balanced in terms of performance, area, and power consumption.

Some PDKs provide multiple standard cell libraries with different numbers of tracks. Backend engineers need to select standard cells with an appropriate number of tracks to design the chip according to the application scenario of the chip. However, after selecting a standard cell library, standard cells with different numbers of tracks cannot be mixed in the circuit. This is different from the threshold voltage, because a standard cell library can also contain standard cells with multiple threshold voltages, and they can be mixed. In fact, ICsprout55 also provides a 9T standard cell library, but it is not open yet.

Physical Design - From Netlist to Tapeout-Ready Layout

Physical design refers to the process of mapping the standard cells and their connection relationships recorded in the netlist to the three-dimensional space of a real chip. Specifically, the EDA tools responsible for physical design need to determine the coordinates of each standard cell in the chip, and also need to determine the direction of the wires, so that the wires can connect the standard cells located at different coordinates according to the connection relationships in the netlist, thereby realizing a function consistent with the netlist logic. The file that records the coordinates of the standard cells and the directions of the wires is the GDS layout file mentioned above. Finally, the EDA tools also need to evaluate whether the obtained chip can be correctly manufactured, whether the indicators of the chip meet expectations, and so on.

After understanding the process structure of the chip, you can understand the essence of physical design. The process of physical design is to determine the content in each layer: what area each layer should select (floorplan), which standard cells should be placed at which positions in the lower layers (floorplan, placement), how to connect these standard cells in the middle layers (routing), how to plan the clock (clock tree synthesis), and how to plan the power in the higher layers (power planning). Below we introduce one by one what work needs to be carried out in each of these stages.

--------------------     M7    <----- Power Planning
  | | | | | | | | |
--------------------     M6    <----- Clock Tree Synthesis
  | | | | | | | | |
--------------------     M5    <-+
  | | | | | | | | |             |
--------------------     M4      |
  | | | | | | | | |             +--- Routing
--------------------     M3      |
  | | | | | | | | |             |
--------------------     M2    <-+
  | | | | | | | | |
--------------------     M1    <-+
  | | | | | | | | |             +--- Floorplan, Placement
=====================  Poly-silicon <-+
+++++++++++++++++++++  dielectric
ooooooooooooooooooooo  Silicon substrate

Since physical design involves real circuits, physical design engineers need to understand the relevant knowledge in the electronics field to do their work well. However, in "One Student One Chip", you only need to roughly understand which steps are involved in converting a netlist into a tapeout-ready layout, thereby helping you understand in the future the mutual influences between logic design (i.e., RTL design) and physical design. You do not need to deeply understand or even memorize all the details in the physical design process.

Floorplan

The main task of the floorplan is to determine the size of the chip and place some cells whose positions will not be adjusted in subsequent processes. The work of the floorplan mainly includes the following contents.

Determining the Chip Size

Similar to the area of standard cells, the die size refers to the area of the projection of the chip on the plane, that is, the area of the rectangle obtained from the top view of the chip. It is also the area of each metal layer in the chip, so it is also called the chip area. The thickness of the chip (i.e., the measure on the -axis) is related to the selected process, such as the 1P7M mentioned above. Generally speaking, after a process is selected, the thickness of the chip is not an adjustable parameter, so the physical design stage usually does not care about the thickness of the chip.

According to the process structure of the chip, the chip area is mainly composed of the area of the transistors and the area of the wires. The area of the transistors mainly includes the area occupied by the source and drain of the silicon substrate, plus the area occupied by the gate of the poly-silicon layer. However, the standard cell library will give the area occupied by each standard cell, so users or EDA tools do not need to consider the dimensions at the transistor level. The wires are divided into two kinds: vertical (i.e., the -axis direction) and horizontal. The former passes through vias between metal layers, and its projection on the plane is a point; the latter extends inside the metal layer, and its projection on the plane is a line. On the surface, neither of these two cases occupies area, but according to the requirements of process manufacturing, there is a minimum spacing between vias and between wires; otherwise, signal interference or even short circuits will occur. Therefore, in reality, wires also occupy a certain area.

Since the routing work has not been carried out yet at this time, the specific area occupied by the wires cannot be obtained. In the floorplan stage, the chip size is generally estimated through the area report obtained by synthesis (i.e., the total area occupied by the standard cells). When estimating, the engineer needs to consider the expected proportion of the total area of the standard cells to the total area of the chip, and this proportion is called the utilization. According to experience, the utilization is generally about 60%~80%. For example, suppose that after the synthesis of a chip, the total area of its standard cells is about , and an engineer expects to achieve a utilization of 70%. Then, in the floorplan stage, the chip size can be estimated as .

The selection of the utilization needs to strike a trade-off between cost and design difficulty. If the utilization is high, it means the space left for the routing stage is small, and the routing stage is prone to congestion and long-distance routing, which increases the net delay, lowers the chip frequency, and may even fail due to excessive congestion, making it impossible to complete the physical design; if the utilization is low, the vacant area in the chip is large, causing waste, and the manufacturing cost of the chip is generally proportional to the area, thereby introducing unnecessary cost overhead.

Engineers need to select the target utilization according to the attributes of the chip and their own experience: for small chips, their topologies are relatively simple, and placement and routing are relatively easy to succeed, so a higher utilization can be set; while for complex large chips, it is not appropriate to set too high a utilization, and enough space needs to be reserved for the routing stage. Experienced engineers can set a higher utilization, while novices can start with a low utilization in the early stage to accumulate experience. In large projects, engineers generally carry out multiple rounds of physical design, and adjust the parameters of the next round according to the design results of the previous round (excessive congestion or too much remaining area), so as to continuously optimize the results of the physical design and achieve the expected performance goals without introducing excessive cost.

Determining the Chip Side Lengths

After determining the approximate area, it is also necessary to consider the dimensions of the chip, that is, the measures of the chip in the -axis and -axis directions. In addition to the synthesized area of the standard cells, the factors affecting the dimensions also need to consider the number of chip pins. The influence of the number of pins is related to the packaging scheme. A common packaging scheme is QFP (Quad Flat Package), in which the pins are distributed around the four sides of the chip, so the chip size is proportional to the number of pins.

         |    |    |
    +----+----+----+----+
    |                   |
 ---+                   +---
    |                   |
 ---+                   +---
    |                   |
 ---+                   +---
    |                   |
    +----+----+----+----+
         |    |    |

A chip pin needs to correspond to an I/O cell, so the influence of the number of chip pins on the chip size is actually reflected through the size of the I/O cells. On one hand, as mentioned above, the size of an I/O cell is several orders of magnitude larger than that of a general standard cell. On the other hand, since some I/O cells need to undertake the task of supplying power and cannot be used for communication, the total number of pins that actually need to be planned is more than the number of pins used for communication. The proportion and distribution density of the power supply pins are related to the attributes of the chip such as size, process, and power consumption. The process-related manual will give the recommended layout of the power supply pins. But generally speaking, the larger the size and the higher the power consumption, the larger the required power supply, and the more the number of power supply pins.

For example, if a chip needs 90 pins for communication, and assuming 1/3 of the pins are needed for power supply, then pins are actually needed, so the common packaging scheme of 144 pins should be selected. If the pins are evenly distributed around the four sides, about pins need to be placed on each side. Suppose the chip is designed with the ICsprout55 process, and the size of an I/O cell is . Suppose this process allows I/O cells to be arranged closely next to each other, then the side length of the chip is , and the minimum area of the chip is . That is to say, even if the chip size is estimated as according to the utilization, after considering the pins and the packaging scheme, the chip area still needs to be planned as . Some processes require a certain gap to be reserved between I/O cells, in which case the side length of the chip will be longer and the minimum area will be larger.

Must the shape of the chip be a square?

The symmetry of a square can reduce the burden of some subsequent work, such as power planning and clock tree synthesis, which require that the distances from the source point to all target points should not differ too much. But in reality, the side lengths of a chip do not have to be the same. As long as the required I/O cells can be placed, the physical design (such as successful routing) can be completed successfully, the chip meets the manufacturing constraints specified by the vendor, and the packaging scheme can be implemented, the chip can be taped out and produced.

Therefore, as a resource, the number of chip pins needs to have its requirements clarified at the specification definition stage in the early stage of the project. At the same time, we can also quickly estimate the minimum area of the chip through the number of pins. For example, if a chip only needs 28 pins for communication, according to the calculation with the same proportion of power supply pins, the 44-pin packaging scheme can be adopted. Under the ICsprout55 process, the minimum area of the chip is .

Another factor that may affect the chip size is special macro cells. Since macro cells have been pre-designed, their shapes are fixed. To place certain special macro cells, the chip size needs to meet certain requirements. For example, some DDR phy modules need to be placed on the I/O boundary of the chip, and their shapes are L-shaped. This requires that the long side of the chip must be longer than the long side of the L-shaped module; otherwise, this DDR phy module cannot be placed.

Combining the above conditions, the size of the chip can be preliminarily determined, and its top view is shown in the following figure.

+-----------------------------------------+
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
|                                         |
+-----------------------------------------+

Placing I/O Cells

After determining the chip size, the next step is to place the I/O cells around the chip. Generally, the placement of I/O cells follows the following practices:

Place the data I/O cells corresponding to functionally similar top-level ports at physically adjacent positions. Data I/O cells logically correspond to the top-level ports of the entire design, and they will be connected to the standard cells inside the chip through wires. Therefore, this placement method helps reduce the net delay in the routing stage (such as the two ports A and B in the following figure). Otherwise, if functionally similar ports are placed on the two sides or even diagonally of the chip, one end must go through a longer wire to reach the target standard cells.

         |    |    |                         |    |    |
    +----+----+----+----+               +----+----+----+----+
    |                   |               |                   |
 A---+--+                +---        A---+--+                +---
    |  o                |               |  o                |
 B---+--+                +---         ---+  +                +---
    |                   |               |  |                |
 ---+                   +---         ---+  +----------------+---B
    |                   |               |                   |
    +----+----+----+----+               +----+----+----+----+
         |    |    |                         |    |    |

Place the corresponding core power cells and I/O power cells according to the requirements for the density of power supply pins in the process manual. For example, a certain process may require placing a power cell every two data I/O cells.

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
|                                         |
|p                                       I|
|                                         |
|P                                       P|
|                                         |          I Data I/O Cell
|I                                       p|          p Core Power Cell
|                                         |          P I/O Power Cell
|I                                       I|
|                                         |
|I                                       I|
|                                         |
|p                                       p|
|                                         |
|P                                       P|
|                                         |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

Placing Macro Cells

Another task is to place macro cells. Macro cells occupy much larger areas than general standard cells. For example, a 64x64 SRAM, considering only the memory cells, needs transistors, while a 2-input NAND gate standard cell only needs 4 transistors. Therefore, macro cells need to be placed in advance; otherwise, after placing the standard cells, it will be difficult to free up a continuous large area to place the macro cells.

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
|                                         |
|p                                       I|
|    +-------+                            |
|P   | MMMMM |                           P|
|    | MMMMM |                            |          I Data I/O Cell
|I   | MMMMM |                           p|          p Core Power Cell
|    +-------+                            |          P I/O Power Cell
|I                                       I|          M Macro Cell
|                            +-------+    |
|I                           | MMMMM |   I|
|                            +-------+    |
|p                                       p|
|                                         |
|P                                       P|
|                                         |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

Similar to the placement of I/O cells, the placement of macro cells also needs to refer to their functions, so that macro cells with similar functions are placed at physically adjacent positions, thereby avoiding long wires in the routing stage, which would affect the frequency of the chip.

Powerplan

The goal of power planning is to plan the distribution of the power supply wires at the chip level, so as to ensure the reliability of the chip's power supply. The work of power planning mainly includes:

Planning the power ring of the I/O cells. From the physical distribution, the power ring of the I/O cells surrounds the I/O cells around the chip and is connected to the power ports of the I/O cells, and is supplied by the I/O power cells in the I/O cells. As mentioned above, to drive the circuits outside the chip, the I/O cells need strong drive strength, so the power supply of the I/O cells is also different from that of general standard cells, and needs to be planned and designed separately.
Planning the core power ring. In physical distribution, it is similar to the power ring of the I/O cells, but it is located inside the I/O cells and surrounds the chip, forming the main trunk of the power supply network. It is supplied by the core power cells in the I/O cells and provides a uniform power supply input to the standard cells inside the chip.
Planning the power stripes inside the chip. From the physical distribution, the power stripes are distributed crisscross inside the chip, and are used to uniformly deliver power to various macro cells and standard cells inside the chip. In the placement stage, these power stripes will be connected to the source and drain of the gate circuits in the standard cells.

For the sake of conciseness, the following figure only shows one power stripe as an illustration; in reality, multiple crisscross power stripes should be planned.

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
| ####################################### |
|p#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#I|
| #% +-------+                         %# |
|P#% | MMMMM |                         %#P|
| #% | MMMMM |                         %# |          I Data I/O Cell
|I#% | MMMMM |                         %#p|          p Core Power Cell
| #% +-------+                         %# |          P I/O Power Cell
|I#%                                   %#I|          M Macro Cell
| #%                         +-------+ %# |          # I/O Power Ring
|I#%                         | MMMMM | %#I|          % Core Power Ring
| #%                         +-------+ %# |          = Power Stripe
|p#%===================================%#p|
| #%                                   %# |
|P#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#P|
| ####################################### |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

In the future, when the chip works, the power enters the chip through the power supply pins, propagates to the surrounding areas of the chip through the power rings, and then propagates to the standard cells in various regions of the chip through the power stripes, applying the corresponding voltages to the source and drain of the transistors, so that they work according to the electrical characteristics of the transistors.

Some complex chips also need to support power management related functions, such as multiple voltage domains and power gating. The planning work related to these functions also needs to be carried out at this stage.

Placement

The goal of placement is to place the standard cells in the chip and determine the physical position of each standard cell in the chip. But the placement of standard cells is not arbitrary; certain rules need to be followed:

Standard cells cannot overlap each other. Although the chip is a three-dimensional object, according to the process structure of the chip, standard cells are realized through the transistors in the lower layers and the connections in the lower metal layers. The transistors of different standard cells should occupy different positions in these layers. That is, the -axis coordinate components of all standard cells are the same. Therefore, from the projection on the plane (i.e., the top view of the chip), standard cells cannot overlap each other.
The placement of standard cells needs to meet certain alignment conditions. The attributes such as the SITE and the number of tracks mentioned above are essentially used to constrain the positions of standard cells during placement. Aligning according to SITE allows the power stripes set in the power planning stage to be easily connected into the standard cells (as shown in the following figure), while the concept of the number of tracks allows the subsequent routing stage to easily meet the minimum spacing requirements of the metal layer wires (i.e., the PITCH attribute). If the placement of standard cells does not meet the alignment requirements, EDA tools will need to spend a great cost to generate a design scheme that meets the process requirements.

        --- +------+  +------------+----------+    +---+
         ^  |======|==|============|==========|====|===| <- VSS power stripe
         |  |      |  |            |          |    |   |
height --+  |      |  |            |          |    |   |
         |  |      |  |            |          |    |   |
         v  |======|==|============|==========|====|===| <- VDD power stripe
        --- +------+  +------------+----------+    +---+
               OR2        AOI221       AND4        NAND2

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
| ####################################### |
|p#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#I|
| #% +-------+  @@  @@  @           @ @%# |
|P#% | MMMMM |   @      @@@      @@  @@%#P|
| #% | MMMMM |  @    @                @%# |          I Data I/O Cell
|I#% | MMMMM |                @        %#p|          p Core Power Cell
| #% +-------+   @   @@           @    %# |          P I/O Power Cell
|I#%                                   %#I|          M Macro Cell
| #% @   @   @   @@  @       +-------+ %# |          # I/O Power Ring
|I#% @    @  @   @   @   @   | MMMMM | %#I|          % Core Power Ring
| #% @   @   @   @   @    @  +-------+@%# |          = Power Stripe
|p#%===================================%#p|          @ Standard Cell
| #% @   @       @   @    @     @     @%# |
|P#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#P|
| ####################################### |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

In addition to making the placement of standard cells meet the requirements of process manufacturing, EDA tools also consider how to improve the quality of the circuit. Some measures include but are not limited to:

Placing logically similar standard cells close together. Similar to the placement of the data I/O cells mentioned above, if two logically similar standard cells are far apart, a high net delay will be introduced in the routing stage, thereby lowering the frequency of the chip.
Mirroring standard cells. As mentioned above, the SYMMETRY attribute in the LEF file indicates that a standard cell can be placed symmetrically along the -axis or the -axis, so as to optimize the effect of the placement (such as the net delay to a certain port, etc.). For example, if the port p on the left side of a standard cell A needs to be connected to another standard cell B located on the right side of A, A can be mirrored along the -axis, so that port p is located on the right side of A, making the distance between p and B shorter and reducing the net delay.
Congestion mitigation. If standard cells are overly concentrated in a certain area, the subsequent routing work may become difficult. This not only causes detours of the wires and introduces a high net delay, but may even cause routing failure due to excessive congestion. To mitigate the congestion, EDA tools may disperse the overly concentrated standard cells, thereby reserving more space for the routing stage.

Size of Filler Cells

Standard cell libraries usually provide filler cells of different sizes, used to fill the blank positions in the chip where no standard cells are placed. Taking ICsprout55 as an example, try to find the size of the smallest filler cell in the related files. What is the relationship between this size and the SITE attribute of the standard cells? Why?

Clock Tree Synthesis (CTS)

The goal of clock tree synthesis is to build a clock network to deliver the clock signal to the clock terminals of all sequential cells. This clock network usually has only one or a few sources (clock pins or the outputs of phase-locked loops). We can regard these sources as root nodes and the sequential cells as leaf nodes. This clock network is like one or several trees growing from the root nodes to the leaf nodes, so it is called a "clock tree".

In the RTL design stage, we consider the clock signal to be ideal. But in reality this is not the case. In the physical design stage, we need to consider the problems that the actual clock signal needs to handle. The special properties of the clock signal have been briefly discussed when introducing "clock-specific cells" above. Therefore, the constructed clock tree should also satisfy these properties, specifically including:

Low latency. There are many factors that introduce delay into the propagation of the clock signal. Some can be optimized by EDA tools, such as the wires of the clock signal; EDA tools should reduce, as much as possible, the distance from the clock source to the clock ports of the flip-flops. Others cannot be optimized by EDA tools, such as the delay of the clock source itself; EDA tools should consider these factors when modeling the delay of the clock signal.
Low skew. When designing RTL, we consider that the ideal clock signal arrives at all flip-flops at the same time. But in reality, different flip-flops are placed at different positions in the placement stage, and the time required for the same clock signal to arrive at different flip-flops is not exactly the same, which gives rise to the concept of clock skew. To reduce the clock skew as much as possible, EDA tools need to carefully plan the wires of the clock signal, so that the net delays from the clock source to each flip-flop are as uniform as possible.
Low jitter. Jitter is a natural characteristic of electrical signals in the physical world, related to specific process parameters, and cannot be optimized or eliminated by EDA tools. Therefore, EDA tools should consider the influence of jitter when modeling the delay of the clock signal. Otherwise, the estimation of the clock signal delay by the EDA tools may be overly optimistic. In the future, when the chip works in real scenarios, the real jitter may make the circuit violate the overly optimistic timing conditions, and finally make the chip unable to work correctly.
High drive. To realize the high drive strength of the clock signal, dedicated clock buffers are generally inserted in the clock tree.

However, there are also certain mutual constraints among these properties. For example, some wire topologies have the property of low skew, but their net delays are high; inserting clock buffers can improve the drive strength of the clock signal, but will also change the delay on the corresponding paths, which may make the skew more serious. Therefore, EDA tools need to comprehensively consider the influence of these techniques on the clock tree, and construct a clock tree that meets the requirements as a whole.

For the sake of conciseness, the following figure only shows a part of the clock tree as an illustration; in reality, the clock tree should be connected to all sequential cells.

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
| ####################################### |
|p#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#I|
| #% +-------+  @@o @@  @           @ @%# |
|P#% | MMMMM |   @o     @@@      @@ o@@%#P|
| #% | MMMMM |  @ o  @    o         o @%# |          I Data I/O Cell
|I#% | MMMMM |    o       o   @     o  %#p|          p Core Power Cell
| #% +-------+   @o  @@   o       @ o  %# |          P I/O Power Cell
|I#% oooooooooooooooooooooooooooooooooo%#I|<-- clk   M Macro Cell
| #% @   @   @   @@o @    o  +-------+ %# |          # I/O Power Ring
|I#% @    @  @   @ o @   @o  | MMMMM | %#I|          % Core Power Ring
| #% @   @   @   @ o @    @  +-------+@%# |          = Power Stripe
|p#%===================================%#p|          @ Standard Cell
| #% @   @       @ o @    @     @   oo@%# |          o Clock Tree
|P#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#P|
| ####################################### |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

Routing

The goal of routing is to connect the standard cells in the placement stage through wires according to the topological relationship of the netlist. As large-scale and very-large-scale integrated circuits, the number of standard cells is very large, and there are also many wires between standard cells. As long as one wire cannot be connected, the routing fails. To improve the probability of successful routing, the routing task is generally divided into two stages: global routing and detailed routing.

Taking the road planning of a city as an analogy, global routing is like planning the main roads of a city. On one hand, the connectivity between different places in the city must be ensured; on the other hand, the main roads must not be overly circuitous, and connectivity should be achieved with as short a distance as possible; finally, excessive congestion in certain areas also needs to be avoided. And detailed routing is equivalent to further dividing the real lanes on the main roads, allowing vehicles to drive on the lanes, so as to reach the places connected by the main roads.

Returning to the routing scenario, the goal of global routing is to plan coarse-grained wire schemes and allocate routing resources for these coarse-grained wire schemes, including the number of tracks, the directions of the wires, and the vias between metal layers, and so on. Specifically, in the global routing stage, the routing tool will regard multiple tracks as a grid, and then try to connect the standard cells through the grid, obtaining some "grid paths" (similar to the main roads in road planning). In the process of global routing, the routing tool will, while ensuring connectivity, find a set of "grid path connectivity schemes" that are relatively short in distance and avoid excessive congestion. The goal of detailed routing is, on the basis of global routing, to determine the tracks of the wires inside the "grid paths", and through these wire tracks, truly connect the standard cells.

+-----------------------------------------+
|  I  I  P  p  I  I  P  p  I  I  P  p  I  |
| ####################################### |
|p#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#I|
| #% +-------+..@@o @@..@...   .....@.@%# |
|P#% | MMMMM |  .@o.....@@@..... @@ o@@%#P|
| #% | MMMMM |..@ o  @    o   .   . o @%# |          I Data I/O Cell
|I#% | MMMMM |  . o       o   @   . o .%#p|          p Core Power Cell
| #% +-------+  .@o  @@...o   ....@ o .%# |          P I/O Power Cell
|I#% oooooooooooooooooooooooooooooooooo%#I|<-- clk   M Macro Cell
| #% @ ..@...@ ..@@o @... o  +-------+.%# |          # I/O Power Ring
|I#% @....@ .@.. @ o @. .@o .| MMMMM |.%#I|          % Core Power Ring
| #% @...@...@  .@ o @  ..@..+-------+@%# |          = Power Stripe
|p#%===================================%#p|          @ Standard Cell
| #% @...@      .@ o @... @.....@.. oo@%# |          o Clock Tree
|P#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%#P|          . Wire
| ####################################### |
|  I  p  P  I  I  p  P  I  I  p  P  I  I  |
+-----------------------------------------+

Up to this point, all the work of physical design has been completed, and the content of each layer in the chip has been determined. The GDS layout file can be generated to describe all the standard cells and wires in each layer of the chip.

Sign-off Analysis

The goal of sign-off analysis is to ensure that the layout obtained through the physical design process is producible. On one hand, it is necessary to ensure that the layout meets the indicators of the front-end design, including PPA and so on; on the other hand, it is also necessary to ensure that the layout meets the production and manufacturing requirements of the wafer fab. Strictly speaking, sign-off analysis does not belong to the category of physical design, but to ensure that the layout is tapeout-ready, sign-off analysis is indispensable; otherwise, the produced chip may not work.

The specific work of sign-off analysis includes but is not limited to:

Static timing analysis. After the physical design work is completed, the positions of all standard cells in three-dimensional space have been determined, and the details such as the directions, lengths, and corners of all wires have become clear. Therefore, the logic delay and net delay of each path in the circuit can be accurately modeled, including the propagation delay, jitter, and skew of the clock signal. Combining these factors, more accurate timing evaluation results can be obtained, so as to determine whether the frequency indicator specified by the user is met.
Power consumption analysis. Similar to static timing analysis, after the physical design work is completed, more accurate power consumption evaluation results can be obtained, so as to determine whether the power consumption indicator specified by the user is met.
Signal integrity analysis. Analyze the crosstalk between adjacent wires, and ensure that signals can still be transmitted correctly without distortion under noisy environments and crosstalk conditions.
Physical Verification (PV for short). Carry out checks on the physical structure of the chip. If violations are found, the placement and routing results need to be modified and checked again. The check work of physical verification specifically includes:
- Design Rule Check (DRC). Ensure that the GDS layout meets the design rules of the wafer fab, including the check rules of the poly-silicon layer and various metal layers, such as the minimum wire width requirement and the minimum spacing requirement. Some PDKs record these rules in files in text form, and EDA tools can read these rules from the files and check them one by one. For example, some rules in a certain PDK are as follows:
```
# The minimum width of the metal1 layer is 65nm
metal1.width(65.nm, euclidian).output("METAL1.1", "METAL1.1 : Minimum width of metal1 : 65nm")

# The minimum spacing of the via6 layer is 160nm
via6.space(160.nm, euclidian).output("VIA6.2", "VIA6.2 : Minimum spacing of via6 : 160nm")
```
- Electrical Rule Check (ERC). Check whether there are electrical problems in the circuit, such as dangling wires and short circuits.
- Layout Versus Schematic (LVS). Confirm the consistency between the GDS layout (physical circuit) and the netlist (logical circuit).

From Tapeout-Ready Layout to a Running Chip

The following steps are also needed from a tapeout-ready layout to a running chip:

After the backend design team submits the GDS layout of the chip to the wafer fab, the wafer fab will fabricate masks according to the layout.
The wafer fab uses the masks to mass-produce wafers. There are multiple dies on a wafer. The wafer fab cuts the wafer to obtain a batch of dies.
The wafer fab hands the dies to the packaging house, which packages the dies according to the planned packaging scheme to obtain finished chips.
The packaging house hands the finished chips to the development board team, which designs the development board and solders the finished chips onto it.
The development board is handed to the user, who deploys software on the chip and runs it.

yyz

# D6 From RTL Code to Tapeout-Ready Layout

# RTL Simulation - Functional Verification

# The Simulation Behavior and Coding Style of Verilog

I can write Verilog, isn't that enough? Why do I need to know these things?

# Execution of Verilog Code

Have you felt that your understanding of Verilog has been subverted?

# Event-Based Simulation

# Hierarchical Event Queue

Verilog Code != C Code

# Event Scheduling for Assignment Operations

A New Understanding of Blocking and Non-blocking Assignments

Use the Event Model to Analyze the Behavior of Verilog Code

# Event Processing Order

# Simulators and Simulation Programs

Understand the behavior of the simulation program generated by Verilator

# Data Races

Analyze the Behavior of Verilog Code Using the Event Model (2)

Analyze the Behavior of Verilog Code Using the Event Model (3)

# Good Verilog Coding Styles

I can write Verilog, so why do I need to know this?

More Examples and Analyses

I can write Verilog, so why do I need to know this? (2)

# Logic Synthesis - From RTL Code to Netlist

The first open-source PDK in China, and the most advanced open-source PDK in the world at the time of release

# Parsing

# Elaboration

# Semantic Analysis

# Intermediate Code Generation

View Structure Diagram

# Coarse-grain Synthesis

# Converting Procedural Descriptions to Coarse-grain Representations

View Structure Diagram (2)

# Optimization

Trade-off Between Area and Performance

View Structure Diagram (3)

# Identification and Processing of Finite State Machines

# Identification and Processing of Memories

# Fine-grain Synthesis

View Structure Diagram (4)

# Technology Mapping

View Structure Diagram (5)

View Structure Diagram (6)

Technology Mapping and the techmap Command of yosys

# Netlist and Report Generation

Understand the Synthesis Process through the yosys Log File

# RTL Synthesis Semantics of Verilog

RTFM

Analyze the Behavior of Verilog Code Using the Event Model (4)

RTFM (2)

Chisel Benefits

# Evaluating Circuits with Open-Source EDA Tools

# Area Evaluation

# Performance Evaluation

The Cost of Faster Speeds

Evaluate the Performance of the Circuit

# Power Consumption Evaluation

Evaluate Circuit Power Consumption

Limitations of Open-Source EDA Tools

So, is an FPGA still needed for learning "One Student One Chip"?

# PDK and Standard Cell Library

# Content of the PDK

# Chip Structure from a Process Perspective

Learn about the metal layers of ICsprout55

Processes with Multiple Poly-silicon Layers

# Attributes of Standard Cells

# LIB Files - Function, Timing, and Power Consumption

RTFM

# Verilog Files - Behavioral Models

# LEF Files - Physical Geometry Information

# CDL Files - Transistor Structure Description

Draw the transistor structure according to the CDL file

# GDS Files - Physical Layout

# Classification of Standard Cells

# Logic Gate Cells

Understand the Function of Complex Logic Gate Cells

Understand the Transistor Structure of OAI22

The Naming of OAI22

Understand the Function of Complex Logic Gate Cells (2)

Understand Drive Strength

Understand Drive Strength (2)

D6 From RTL Code to Tapeout-Ready Layout

RTL Simulation - Functional Verification

The Simulation Behavior and Coding Style of Verilog

Execution of Verilog Code

Event-Based Simulation

Hierarchical Event Queue

Event Scheduling for Assignment Operations

Event Processing Order

Simulators and Simulation Programs

Data Races

Good Verilog Coding Styles

Logic Synthesis - From RTL Code to Netlist

Parsing

Elaboration

Semantic Analysis

Intermediate Code Generation

Coarse-grain Synthesis

Converting Procedural Descriptions to Coarse-grain Representations

Optimization

Identification and Processing of Finite State Machines

Identification and Processing of Memories

Fine-grain Synthesis

Technology Mapping

Netlist and Report Generation

RTL Synthesis Semantics of Verilog

Evaluating Circuits with Open-Source EDA Tools

Area Evaluation

Performance Evaluation

Power Consumption Evaluation

PDK and Standard Cell Library

Content of the PDK

Chip Structure from a Process Perspective

Attributes of Standard Cells

LIB Files - Function, Timing, and Power Consumption

Verilog Files - Behavioral Models

LEF Files - Physical Geometry Information

CDL Files - Transistor Structure Description

GDS Files - Physical Layout

Classification of Standard Cells

Logic Gate Cells

Sequential Cells

I/O Cells

Driver Cells

Physical Cells

Macro Cells

Complex Function Units

Clock-Specific Cells

Power Management Cells

Test and Debug Cells

PVT Corners

Threshold Voltage

Try Different Threshold Voltages

Number of Tracks

Physical Design - From Netlist to Tapeout-Ready Layout

Floorplan

Determining the Chip Size

Determining the Chip Side Lengths

Placing I/O Cells

Placing Macro Cells

Powerplan

Placement

Clock Tree Synthesis (CTS)

Routing

Sign-off Analysis