150 validation checks - fractal technologies · 11/1/2013 quality in design formats 2 parser checks...

30
11/1/2013 Fractal Technologies Confidential Fractal Technologies Validation checks for: -Standard cell Libraries -IO lib and IP (Design Formats)

Upload: vothuy

Post on 02-Feb-2019

218 views

Category:

Documents


0 download

TRANSCRIPT

11/1/2013 Fractal Technologies

Confidential

Fractal Technologies

Validation checks for:

-Standard cell Libraries

-IO lib and IP

(Design Formats)

11/1/2013 Quality in Design Formats 2

Parser Checks

• Front End – Verilog (1995,2001,SystemV,AMS) – Tetramax – Fastscan (atpg) – VHDL – Liberty (.lib) (NLDM, CCS, CCSN, ECSM, NLPM) – Cadence TLF

• Binary Design Databases – MilkyWay (CEL, FRAM…) – Cadence DFII (all views) – Open Access (all views)

• Simulation/Schematics – Spice (Hspice, CDL) – Spectre – All Binary DB schematics

• Back End – GDSII – OASIS – LEF and DEF – .plib

• Others (IP related) – STIL/CTL – SPEF

• Custom parsers – Documentation (text, html, PDF…) – Lvision – .slib

- Syntax of the respective formats is checked

– On demand all ASCII based formats

11/1/2013 Quality in Design Formats 3

Cell-presence

• Based on a reference list or designated format the

presence of all cells is checked in all the other formats

– Classes of cells (e.g. Schematic-cells, Filler-cells, etc…)

– Reports missing cells

– Reports obsolete or additional cells

– Hierarchical databases are checked for completeness

• Reports missing sub cells

• Supports:

– All Formats

11/1/2013 Quality in Design Formats 4

Terminals & Pins

• Reports wrongly named pins based on a Golden Reference format.

• Reports missing pins based on a Golden Reference format

• Reports pins with inconsistent direction (INPUT, OUTPUT, BIDIRECTIONAL)

• For buses width and brackets can be checked

• Checks for back-end formats if the pins are in the correct layer designation (e.g. “M1 pin”)

• Exceptions are handled

(e.g. missing VDD, GND)

• Supports:

– All formats

Golden

Reference

Checked

Format

11/1/2013 Quality in Design Formats 5

Pin-Labels

• Reports if text labels are missing based on the pins in

the Golden Reference format

• Checks if the text labels are in the correct layer

designation (e.g. “M1 TEXT”)

• Brackets for buses

• Supports:

– All Back-End formats

11/1/2013 Quality in Design Formats 6

Nets

• Checks if formats with a “net” concept have nets with the

same name as the pins

• “net” concept formats are:

– Cadence DFII

– Open Access

– MilkyWay (FRAM)

11/1/2013 Quality in Design Formats 7

Layout vs. layout

• Checks identity between polygons (Two Styles):

– layout-vs-layout

• Performs Boolean mask XOR operations

– abstract-vs-layout

• Abstract always encloses the “layout” polygons.

• Detailed check example:

– “M1 net”+”M1 boundary” in abstract >= “M1 drawing”+”M1 pin” in layout

• Handles “stair casing”

• Supports:

– All Back-End formats

11/1/2013 Quality in Design Formats 8

Typical Layout vs. layout Errors

• Modifications in the master Cadence Database not copied to

GDSII or LEF

• 45 degrees not

accurately enough

in LEF

• Abstract not

generated correctly

• Shifted polygons

11/1/2013 Quality in Design Formats 9

LEF cells Check

• Checks if LEF cells have the correct size according to

LEF technology

• Supports

– LEF only

11/1/2013 Quality in Design Formats 10

Routability

• Checks if signal-pins can be routed to cell-boundary

– Uses fast internal gridded maze router

– Users select layers (e.g. M1 only) or special rules (e.g.

double-via’s on outputs of high-drive cells)

– Technology settings (rules, vias, pitch) read from LEF

technology

– Supports:

• LEF

• PLIB

• MilkyWay (FRAM)

11/1/2013 Quality in Design Formats 11

Typical Routability Errors

• Pins not on grid

• Wrongly coded off-set

11/1/2013 Quality in Design Formats 12

Abutment

• All cells checked for self-symmetry and left/right

abutment (alignment on cell-boundary) with reference

cell:

• This is NOT a boundary DRC check

• Double, triple, etc… height cells are supported

• Supports:

– All Back-End formats

11/1/2013 Quality in Design Formats 13

Typical Abutment Errors

• 1 grid shift

• Missing boundary layer

• Layers do not touch the

outline

11/1/2013 Quality in Design Formats 14

Functional Equivalence

• Checks for functional equivalence between:

– All schematic netlists (Spice, CDL, Schematic views)

– Liberty, Verilog, VHDL

– All formats that implicitly (schematic) or explicitely hold a

functional description of a cell.

• Supports Boolean, UDP, State Tables, Truth tables

• Counter example of errors are given

• Based on formal verification (for Schematics)

11/1/2013 Quality in Design Formats 15

Typical Functional Equivalence Errors

• Both active RESET and SET yield different result over the

various formats

– Priority definitions wrong

• Mismatch between asynchronous and synchronous

descriptions

• Missing functional description

• Short circuit detection

• Cont…

11/1/2013 Quality in Design Formats 16

Typical Functional Equivalence Errors

• Documentation errors

– Due to missing formal checking. (Depends on human reading)

Datasheet

.lib pin(OA1) { direction : output ;

function : "(!M2|(M1&M0))" ;

pin(OA2) { direction : output ;

function : "(M2|(!M1&!M0))" ;

pin(Z) { direction : output ;

function : “!(M1^M0)" ;

11/1/2013 Quality in Design Formats 17

Timing Characterization: Cross Format

• Check if all timing arcs exists

– Identical timing arcs and conditions for all Liberty files

– Identical timing arcs and conditions for all Verilog files

– Identical timing arcs and conditions for all VHDL files

– Identical timing arcs and conditions for all TLF files

– All combinations above

– For “delay arcs” and “timing check arcs”

– SDF back annotation check • string compare of the conditions

– Power arcs present based on the timing arcs

– Condition completeness check

– Condition obsolete check

– When vs. SDF condition check (When == SDF)

– Correct terminal transition check (positive/negative/none unate)

11/1/2013 Quality in Design Formats 18

Timing Characterization: NLDM

• Index checks

– Delay table accompanied by transition table

– Ascending Capacitance and transition indices

– Capacitance indices of all tables are identical for each cell

– Transition indices of all tables are identical for each cell

• Table Value Checks

– Delay values within user defined range

– Transition values within user defined range

– Setup/hold values within user defined range

– Clock period within user defined range

– Increasing delay values with increasing output load

– Increasing delay values with increasing input transition

– Setup and hold defined in matching pairs

– Matching setup and hold have equal indices

– Setup + hold > 0

• Trend checks

– Compare and plot 2 NLDM tables

– Plot trends in histogram (PVT, bc, tc, wc)

– Delay decreases for cells with increasing drive strength

– Delay decreases with decreasing temperature

– Delay decreases with decreasing voltage

– Delay decreases from (wc, tc, bc)

• Property checks

– Capacitance property of pins must be present and not negative

– The max. capacitance index value must not be larger than the max_capacitance property

– Max_transition property of pins must be present and not negative

– The max. transition index value must not be larger than the max_transition property

– Asymmetrical trip points are not allowed

• Attribution checks

– Pulse_width must be present for all CLOCK pins

11/1/2013 Quality in Design Formats 19

Typical Characterization Errors

• Last characterization entries all 0.

• Delay decreases with increasing output load

• Conditional vs non-conditional descriptions

• Back-annotation errors

– Conditions don’t match string based

• Obsolete default conditions

• Non-paired setup and hold times

• Swapping of Liberty file names ff, tt, vs ss

11/1/2013 Quality in Design Formats 20

Timing Characterization: CCS

• CCS Index checks – CCS waveforms are present for all NLDM tables

– Number of samples for a CCS curve (at least 6 (UserDef))

– CCS index times > 0

– CCS reference time > 0

– CCS index values are monotonic

– Index_1/Index_2 = (capacitance/transition) or vise versa • Index_3 = time

• CCS table values – CCS current values must have at least 6 significant numbers

– CCS receiver cap. values must have at least 6 significant numbers

• CCS reference time check – > 0

– Same for all identical transition times

– Increasing with increasing transition times

• CCS peak position check – Peak must not be 1st or last

– Single peaks

– Peaks increasing with increasing output cap.

• CCS threshold passage check – Integrated current curve (voltage) must pass 1st and 2nd trip points

– Integrated current curve (voltage) must reach nominal voltage

• CCS accuracy check – Delay points calculated from CCS data must be within 2% of NLDM delay points

– Transition points calculated from CCS data must be within 10% of NLDM transition points

11/1/2013 Quality in Design Formats 21

Typical CCS Characterization Errors

• Cells do not have a single

peak current

• Current curves have a

“correction current” at the

tail

11/1/2013 Quality in Design Formats 22

Timing Characterization: ECSM

• ECSM Index checks – ECS waveforms are present for every NLDM transition

– Number of samples for a ECSM curve (atleast 6 (UserDef))

– ECSM index values are normalized [0:1]

– ECSM index boundary check (User defined boundaries)

– ECSM index values are monotonic

• ECSM table values – ECSM waveform values (time) must be increasing

– ECSM waveform values (time) must be within user defined range

– ECSM capacitance values must be within user defined range

• ECSM threshold passage check – ECSM voltage curve must pass 1st and 2nd trip points

– ECSM voltage curve must reach nominal voltage

• ECSM accuracy check – Delay points calculated from ECSM data must be within 2% of NLDM delay points

– Transition points calculated from ECSM data must be within 10% of NLDM transition points

11/1/2013 Quality in Design Formats 23

Typical ECSM Characterization Errors

• ECSM-curves have large deviations (20-300%) between

ECSM and NLDM delay values

11/1/2013 Quality in Design Formats 24

Power Characterization: NLPM

• Index checks

– Transition and capacitance indicess must be equal to

NLDM table

• NLPM table values

– NLPM values are within user defined range

• NLPM trend check

– Power increases with increasing temperature

– Power increases with increasing voltage

• Presence of NLPM power tables

11/1/2013 Quality in Design Formats 25

Miscellaneous checks

• Busses

– Checks for busses when they may not be used

– Check for “bus” naming convention

• Layout checks

– Check area of real layout with “Front-End” statements

– Boundary layer is on a correct grid

– Does the boundary match the cell statements (dimension/origin)

– Check for ½ designrule distance at the boundary

– Is the boundary layer on the top-level

– Text hierarchy (e.g. cell text on top-level, pins on top-level…)

• Time stamp check

• Tests can be created on demand

11/1/2013 Quality in Design Formats 26

Reporting

• Reporting is possible in

– SQL database: Stores last 10 runs

– Text : ASCII readable log files

– CSV : 2 possible styles

– HTML: 2 possible styles: On a per “rule” or per “view” basis

11/1/2013 Quality in Design Formats 27

Waivers

• Waivers on undesired errors or messages can easily be defined

Create new waiving rules

Store waive rules and execute when needed

11/1/2013 Quality in Design Formats 28

Not performed checks

• DRC

• LVS

• Simulation

– Performed by the functional equivalence check

11/1/2013 Quality in Design Formats 29

Conclusions

• ~150 possible checks standard included

– Back-End

– Front-End

– Timing Characterization Checks

– Functional

– Consistency over formats

– Completeness

– Custom designed if necessary

11/1/2013 Quality in Design Formats 30

Conclusions

• Crossfire

– Easy to use and set up

– Easy to view and trace library errors

– Waiving of false/uninteresting errors/messages

– Reporting in HTML, CSV

– Built-in integrity and quality checks

– Extendable to include library/flow specific checks

– Extendable to proprietary formats and databases

– Can run all existing, trusted checks

• Fractal is the perfect partner for consolidating your existing Validation Flow

and to perform the Validation for its Customers

– Expert knowledge and experience on Validation Flows

– Expert knowledge on usage of Crossfire and/or API Module