Static Timing Analysis using Primetime
Synopsys Primetime is widely used in static timing analysis of full chip gate level designs to close timing prior to tapeout. A typical primetime flow with design inputs is shown below.
Static Timing Analysis Flow using Primetime
Primetime is capable of analyzing multi-clock asynchronous/synchronous designs with internally generated clocks and timing exceptions. Multi-corner analysis (fast, slow, bc/wc) and on-chip variation with signal integrity checks (crosstalk) is also supported in Primetime. Primetime supports
- Maximum/minimum capacitance, fanout and transition checks
- Setup/hold/recovery and removal checks
- Reports clock insertion delays, skew, clock gating check violations and data checks
Primetime inputs include
- Library database in standard .db format - the library elements include technology standard cell and IO library (65 nm/130 nm), hard macros like PLLs, SERDES and any custom cells. The libraries are characterized in slow and fast corners to run analysis in multiple corners.
- Design constraints in SDC format - clock definitions, timing exceptions, case analysis and IO constraints. Usually, a design supports multiple modes where the clock can run at different frequencies depending on the mode. Case analysis constraints propagate the appropriate path for each mode, also DFT mode runs are also supported.
- Timing models for blocks or analog blocks like PLL to make run times faster and factor in timing characteristics. Timing models can be
- Quick Timing Model - a preliminary timing model created using PT.
- ILM (interface logic model which includes only the first stage of flops surrounding the IOs and the guts of the block is all blackboxed),
- Extracted timing model that includes only timing arcs between inputs and outputs
- Stamp model that defines the timing in a standard descriptive format.
- Routed netlist from physical design in VHDL/Verilog
or db format.
- Parasitics - Interconnect Delay in SPEF/DSPF format and cell delay in SDF format.
- Incremental delays in SDF format from crosstalk analysis
Primetime breaks down the design into multiple timing paths with one startpoint (flop/input port) and one endpoint (flop/output port). Setup/Hold checks and IO checks are covered in earlier posts, we will cover commonly used primetime commands in our next post.
Sphere: Related ContentInterfaces in SystemVerilog - 2
SystemVerilog allows tasks and functions to be declared within interface definitions known as interface methods. The task or function has the same syntax as when declared in a module. Using these interface methods, the communication protocol details can be embedded within the interface definition itself.
-
interface ahb_bus (input logic ahb_hclk, ahb_hresetn); // Interface can have ports.
-
wire [31:0] ahb_hdata;
-
wire [31:0] ahb_addr;
-
logic ahb_hwrite;
-
logic [1:0] ahb_htrans;
-
logic [2:0] ahb_hsize;
-
logic [2:0] ahb_hburst;
-
logic ahb_hready;
-
logic [1:0] ahb_hresp;
-
-
// Task defined internal to interface
-
task slave_read ( input logic [31:0] raddr);
-
// ...
-
endtask
-
-
endinterface
Interface methods can also be imported if they are not defined within the interface definition itself. If an interface is connected using modport construct, then the import keyword is used to specify the method. Alternative way is to add the task keyword next to the import and also include function arguments - this is required if the task is exported from an external module.
-
interface ahb_bus (input logic ahb_hclk, ahb_hresetn); // Interface can have ports.
-
wire [31:0] ahb_hdata;
-
wire [31:0] ahb_addr;
-
logic ahb_hwrite;
-
logic [1:0] ahb_htrans;
-
logic [2:0] ahb_hsize;
-
logic [2:0] ahb_hburst;
-
logic ahb_hready;
-
logic [1:0] ahb_hresp;
-
-
modport slave ( import slave_read, // simplest way of importing tasks
-
inout ahb_hdata,
-
input ahb_haddr,
-
input ahb_hsize,
-
output ahb_hready,
-
---
-
);
-
-
// Alternative explicit way
-
modport slave ( import task slave_read (input [31:0] addr), // explicit
-
inout ahb_hdata,
-
input ahb_haddr,
-
input ahb_hsize,
-
output ahb_hready,
-
---
-
);
Importing a task or a function through a modport gives the module access to that task by prepending the interface port name to the task name as with other variables. The imported function/task must be declared as automatic in order to be synthesizable.
SV also includes a way to export a task defined in one module to be available to other modules through an interface. For example, if a function is defined in module A and is exported in the modport construct within interface definition using the
It is also possible to define a task or function using extern keyword without associating it with the modport construct.
-
interface shb_bus (....)
-
---
-
extern check_parity (input logic [31:0] data); // Not associated with modport
-
-
modport ahb_slave (...);
-
-
endinterface
-
-
module A (...);
-
-
task check_parity (input logic [31:0] data);
-
// --
-
endtask
-
endmodule
Interfaces can also contain procedural blocks like always, always_ff, parameters and generate statements similar to modules.
Sphere: Related ContentInterfaces in SystemVerilog
Connectivity across different design modules in Verilog
To resolve this issue, SystemVerilog adds a powerful interface construct to encapsulate the communication between blocks i.e. multiple signals are grouped together to form a single port. The signals declared in the interface definition is in a single location so that any changes in the interface can be captured accurately modifying only once instead of multiple modules as in Verilog. All the modules using this interface need only declare a single interface type port rather than multiple signals. An example of SV interface is below
-
// AHB Interface Definition
-
interface ahb_bus (input logic ahb_hclk, ahb_hresetn); // Interface can have ports.
-
// These external signals (hclk, hresetn can be implicitly connected between modules
-
wire [31:0] ahb_hdata;
-
wire [31:0] ahb_addr;
-
logic ahb_hwrite;
-
logic [1:0] ahb_htrans;
-
logic [2:0] ahb_hsize;
-
logic [2:0] ahb_hburst;
-
logic ahb_hready;
-
logic [1:0] ahb_hresp;
-
endinterface
-
-
// Top level Module
-
module ahb_top (input logic ahb_hclk, ahb_hresetn);
-
-
ahb_bus bus (
-
.ahb_hclk(ahb_hclk),
-
.ahb_hresetn(ahb_hresetn) ); // instance of interface
-
-
arm_core arm_inst (
-
// ahb_bus ports
-
.bus (bus),
-
// other ports
-
.port1 (port1) // not part of the interface
-
... );
-
-
ahb_slave ahb_slave0 (
-
.bus (bus) );
-
-
dma_master dma_master_inst (
-
.bus (bus),
-
// Other ports
-
---
-
);
-
-
on_chip_mem on_chip_mem_inst (
-
.bus (bus),
-
// Other ports
-
--
-
);
-
-
endmodule
-
-
// Module Definitions
-
module arm_core (
-
ahb_bus bus, // interface port
-
// other ports
-
input logic port1
-
);
-
// functionality
-
endmodule
-
-
module ahb_slave (
-
ahb_slave bus
-
);
-
logic [1:0] ahb_hsel;
-
logic [31:0] slave_address;
-
// functionality
-
// Referring signals inside interface requires using interface port name
-
assign bus.ahb_addr = (ahb_hsel == 2'b0) ? slave_address; 'z;
-
endmodule
-
-
module dma_master (
-
ahb_bus bus;
-
// Other ports
-
---
-
);
-
// functionality
-
endmodule
An interface can also have tasks, functions, parameters, procedural blocks and type declarations to aid in defining the communication protocol. SV interface cannot have a design hierarchy i.e. no modules can be instantiated in the interface. A modport constructs is provided to define the direction for interface port for different modules. Selecting the appropriate modport for each module can be accomplished during either module definition or during module instance as shown in example below.
-
interface ahb_bus (input logic ahb_hclk, ahb_hresetn); // Interface can have ports.
-
wire [31:0] ahb_hdata;
-
wire [31:0] ahb_addr;
-
logic ahb_hwrite;
-
logic [1:0] ahb_htrans;
-
logic [2:0] ahb_hsize;
-
logic [2:0] ahb_hburst;
-
logic ahb_hready;
-
logic [1:0] ahb_hresp;
-
-
modport master ( inout ahb_hdata,
-
output ahb_haddr,
-
output ahb_hsize,
-
input ahb_hready,
-
---
-
);
-
-
modport slave ( inout ahb_hdata,
-
input ahb_haddr,
-
input ahb_hsize,
-
output ahb_hready,
-
---
-
);
-
endinterface
-
-
module ahb_top (.. );
-
-
ahb_bus bus (...);
-
dma_master dma_master_inst (bus.master); // Use the master modport view
-
ahb_slave ahb_slave0 (bus.slave); // Use the slave modport view
-
-
endmodule
-
-
// Alternatively, modport construct can be used in module definition
-
module ahb_slave (ahb_bus.master bus);
-
endmodule
If no modport is associated with a module, by default all net types are inout and all variable types are ref.
A generic interface port defines the port type using the keyword interface instead of using a name of a specific interface type - the advantage is being able to connect the module to different interfaces. Unlike Verilog, no interface port can be left unconnected and SV .name and .* connection rules can be also be used for interface instances.
-
module ahb_slave (interface bus); // generic interface port
-
ahb_slave ahb_slave0 (bus.slave);