One of the major differences between software and hardware is the concept of a clock. It defines the rhythm the sequential elements update inside the chip. Note that in complex System-On-Chips (SoC) there are many clock frequencies that distribute to parts of the silicon. In this post, we will take a basic look at a clock. At the bottom of this post, you will find links to the previous posts. The “ASIC FUNDAMENTALS” series of blog posts starts with “synchronous design” and the rest follows chronologically after that first post. In this post, we talk about the clock as the principal driving force of synthesis and Static Timing Analysis (STA).
A clock simplifies synthesis
We introduced the clock and synchronous design in previous posts in our series. Our Hardware Description Language design is synchronous, so let’s assume we have only one system clock in the design. Our example design comprises 10 units from 10 different designers. They all develop independently of one another. This is significant since in the real world, most complex digital designs have hundreds of units. Some are IP that we cannot touch (IP contract) or subcontractors design some of our HDL code. Hence our design reflects the way we distribute our design over many. Every time we integrate a new unit, we need to make sure the unit is “clean”. So, we have 10 units and a top level. The latter is the wired up version of those units. Our description of the design is agnostic of the technology we target. The synthesis engineer takes in the HDL code and uses an EDA tool called the synthesis tool. It takes the design source, a library with technology specific cells and the constraints. It translates the HDL into another HDL file we call a “netlist”. A netlist comprises the digital cells and wires that together form the digital function of our top level design. In synchronous design, every path between the output of a flip-flop and the input of the next flip-flop needs to comply to the clock period constraint. Hence we have the following to consider for a rising edge clock. We define D1, Q1 for flip-flop #1 and D2, Q2 for flip-flop #2 whereby D is data input and Q is data output.
This we consider:
- The hold time of D1 after the current rising edge of the clock.
- A delay from the current rising edge to Q1.
- An asynchronous path from Q1 to D2.
- D2 setup time for the next rising edge of the clock.
The synthesis configuration script reads the source code and cell library and sets the constraints for the design. It also sets the effort and importance of each constraint and last but not least, it writes out reports. Constraints are part of three categories: time, area and power. If we met all constraints, synthesis is complete. The netlist is ready to move to the next phase in the project. Whenever we have constraint violations, the root cause is constraints or the source code itself. The output netlist isn’t clean. The one clock example is quite easy compared to complex Systems-On-Chip (SoCs) with many asynchronous clock domains.
Pro-tip 1:
My lean methodology for design, assumes that every unit output is an output of a sequential element. All outputs are registered outputs. It allows to compile a unit for simulation and for synthesis as well. The unit itself must respect the clock period constraint. Doing synthesis on RTL units, makes sure no obvious timing violating paths go to the synthesis stage. RTL design changes for synthesis and STA violations are time consuming.
Static Timing Analysis (STA)
In contrast, the STA tools are not creating a netlist like synthesis tools do. They take the output of the synthesis tool and verify timing only. Hence the input for the STA tool is a netlist, the cell library and constraints for timing. Those timing constraints specify:
- The clocks in the design and their relationship to each other.
- Multi cycle paths. Example: pipelined multipliers are waiting a few clock cycles until the calculation finishes. The path is using multiple clock cycles and the design guarantees correct operation.
- False paths, some situations that the tool considers are not valid in our design. It is important to guide the tools to skip situations that are not real. With the incredible power to exclude things, comes great responsibility. Making a mistake by excluding a path that is real, is a potential disaster.
Pro-tip 2:
Lint tools sometimes do Clock Domain Crossing (CDC) analysis. I am one of those people that runs synthesis, STA and CDC checks (Spyglass). Because the customer wants me to. In the lean methodology I use when I am the project leader, I use a naming convention for synchronizer flip-flops. Via a simple command line “grep”, I can see a list of synchronizers. I immediately see if a clock domain crossing has synchronizers or not. If not, it must be a false path. It saves a lot of money on EDA tool licenses.
What did we learn in this post?
A synthesis tool generates a netlist, cells and wires to connect them. It uses the design constraints to generate reports on those constraints. Especially useful when the tool cannot meet the constraints (time, area, power). The STA tools check the timing paths inside the netlist output from synthesis. Hence STA is only for timing analysis.