top of page

Introduction

Physical Design is used for both the semi and customer design. In the semi approach the hardware is developed by the foundry on a different timeline from the design and development of the design itself. Physical design is the most common term used by most foundries especially for their customers. Physical Design is referred in multiple approach.  

PnR (placement and routing).

Sem-custom flow.

Implementation.

Netlist to GDSII

Physical Design

Backend

You can easily find physical design tools in the market, thus making it difficult to write a generic tutorial on the physics of physical design. The most common tools used in physical design are:

Talus (Earlier blast fusion) from Magma Design Automation.

ICC compiler (earlier Astro/PC ) from Synopsys.

Olympus from Mentor Graphics (acquired from Sierra Design Automation)

There are other kinds of tools. One of them is the optimization tool called Azaro that makes quite a stir in the semiconductor industry. It’s kind of software tool that is used (and I know of them) and creates a very efficient execution flow in a given software. Every tool has its own environment and command methodology, making it hard to describe and acquire quickly.

1.1 Basics
footer

We will cover some basic topics which are needed to understand and learn about basic design. These topics include file types, terminologies etc.

1.1.1 Multiple File/Database types

Milkyway library: Design Libraries or Designer Libraries are databases that hold information about the circuits or circuits from which you generate your physical files. Since design data is in a binary format, it is difficult to work with but not in ICC. This is a very nice feature and gives engineers and designers flexibility to handle their design data in ICC.

Netlist: Netlist(netlist) is just a collection of cells and nets connecting ports of these cells. It can be written hierarchically. A module can be defined, (instantiated) and used to represent a circuit. Netlist can be represented as a hierarchy, which means that you can build a hierarchy on top of another hierarchy. Hierarchy may be expressed as a set of design units. Here is a small netlist example:

Module design (i0, i1, i2, out);

input [1:0] i0;

input i1;

input i2;

output o;

wire net1, net2, net3;

AND2X2 u0(a.(i0[0]), .b(i1), .o(net1));

AND2X2 u1(.a(net1), .b(i2), .o(net3));

NOR3X5 u2(.a(i0[1]), .b(net2), .c(i1), .o(net3));

MUX2X4 u3(.d0(net1), .d1(net3), .s(i2), .o(out));

Endmodule

Liberty: Design Libraries or Designer Libraries are databases that hold information about the circuits or circuits from which you generate your physical files. Since design data is in a binary format, it is difficult to work with but not in ICC. This is a very nice feature and gives engineers and designers flexibility to handle their design data in ICC.

FRAM: FRAM is an abstract view of a cell, or rather the cell’s geometry. It’s the Synopsys internal binary format used by routers to understand how a cell is constructed and to locate certain pins in a device. It contains information about blocked regions in a cell. FRAM will tell a router what layer a pin is located on.

LEF: Library exchange format (LEF) includes two types of information. One is abstract information about the physical properties of a cell and the other is the routing rules. LEF is text files that contains information about pins and how they are connected to layers. LEF also contains the routing rules to show where there are blocks inside a cell and which areas of the cell are blocked. Frame routing files contain information about where ports on a cell are connected and the spacing of the cell is needed for correct routing of nets. Technology related data will provide pin definitions and information about layers and the definition of various grids, spacing and routing rules.

DEF: DEF(Design Exchange Format) is a text format that contains the net list, floorplan, power plan, pin geometrics, cell layout and routing information. It also has a lot of data for design tools such as regions and routing rules etc. DEF is a text file containing all of this design information.

SDC: SDC stands for "Synopsys Design Constraints". This is a data file used to constrain the timing of the design. SDC contains the following information:

  • Clock definitions: The clock definition is on pins with waveforms (time period and duty cycle).

  • IO constraints: Defines the input and output delays on the input and output ports. These are needed by the driver to know when a specific data arrives at the input port or that a certain number of signals have been latched and the output port has received that number of signals. Also defines the boundary conditions on the input and output ports.

  • Timing exceptions: There are exceptions defined in terms of false timing path, multicycle path, asynchronous clocks etc.

  • onstants: Defines constants 1’b1 or 1’b0 on pins in the design.

Tech file: The technology file in Synopsys internal format contains the technology data related to represent layers, grids, and routing. The tech file contains information on the width and spacing of the cells (e.g., the minimum space between two metal levels), as well as the size of the wiring rules used by the engineers to create the layouts.

TLUplus: TLU+ files are Synopsys' internal binary format file containing data in the form of (RC) extraction. Without these files the parasitic extraction tool can still be run in the Techfile.

Routing

bottom of page