0% found this document useful (0 votes)
29 views92 pages

Chapter 4

This document discusses IP core design, modeling, and verification. It covers topics such as designing IPs for reuse, parameterizing IP designs, using IP generators, and creating reusable test suites.

Uploaded by

Nani Ganesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
29 views92 pages

Chapter 4

This document discusses IP core design, modeling, and verification. It covers topics such as designing IPs for reuse, parameterizing IP designs, using IP generators, and creating reusable test suites.

Uploaded by

Nani Ganesh
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 92

Chapter 4

IP Core Design, Modeling and Verification

C. W. Jen 任建葳
[email protected]
Outline
• IP Core Designs
Institute of Electronics, National Chiao Tung University

• IP Core Verification
• IP Core Modeling and Deliverables
• System-Level Verification
IP Core Design, Modeling and Verification

1/91
Outline
• IP Core Designs
Institute of Electronics, National Chiao Tung University

• IP Core Verification
• IP Core Modeling and Deliverables
• System-Level Verification
IP Core Design, Modeling and Verification

2/91
Problem in SoC Era
• Productivity gap
Institute of Electronics, National Chiao Tung University

• Time-to-market pressure
• Increasing design complexity
– HW/SW co-development
IP Core Design, Modeling and Verification

– System-level verification
– Integration on various levels and areas of expertise
– Timing closure due to deep submicron

Solution: Platform-based design with reusable IPs

3/91
Design for Reuse IPs
• Design to maximize the flexibility
Institute of Electronics, National Chiao Tung University

– configurable, parameterizable
• Design for use in multiple technologies
– synthesis script with a variety of libraries
IP Core Design, Modeling and Verification

– portable for new technologies


• Design with complete verification process
– robust and verified
• Design verified to a high level of confidence
– physical prototype, demo system
• Design with complete document set

4/91
Parameterized IP Design
• Why to parameterize IP?
Institute of Electronics, National Chiao Tung University

– Provide flexibility in interface and functionality


– Facilitate verification
• Parameterizable types
IP Core Design, Modeling and Verification

– Logic/Constant functionality
– Structural functionality
• Bit-width、depth of FIFO、regulation and selection of sub-
module
– Design process functionality (mainly in test bench)
• Test events
• Events report (what, when and where)
• Automatic check event
– Others4 (Hardware component Modeling, 1996)

4Authors: Vicktor Preis and Sabine Marz-Rossel, Modeling Highly Flexible and Self-generating Parameterizable Components In VHDL
Collected in book "Hardware component Modeling", 1996, by Jean-Michel Berge, Oz Levia and Jacques Rouillard 5/91
IP Generator/Compiler
• User specifies
Institute of Electronics, National Chiao Tung University

– Power dissipation, code size, application performance,


die size
– Types, numbers and sizes of functional unit, including
IP Core Design, Modeling and Verification

processor
– User-defined instructions.
• Tool generates
– RTL code, diagnostics and test reference bench
– Synthesis, P&R scripts
– Instruction set simulator, C/C++ compiler, assembler,
linker, debugger, profiler, initialization and self-test code

6/91
Logic/Constant Functionality
• Logic Functionality • Constant Functionality
Institute of Electronics, National Chiao Tung University

– Synthesizable code – Synthesizable code


always @(posedge clock) begin assign tRC_limit=
if (reset==`ResetLevel) begin (`RC_CYC > (`RCD_CYC + burst_len)) ?
… `RC_CYC - (`RCD_CYC + burst_len) : 0;
IP Core Design, Modeling and Verification

end
else begin – For test bench
… always #(`T_CLK/2) clock = ~clock;
end …
initial begin
end
#(`T_CLK) event_1;
#(`T_CLK) event_2;

end

7/91
Reusable Design - Test Suite
• Test events
– Automatically adjusted when IP design is changed
Institute of Electronics, National Chiao Tung University

– Partition test events to reduce redundant cases when test for all
allowable parameter sets at a time
• Debug mode
– Test for the specific parameter set at a time
IP Core Design, Modeling and Verification

– Test for all allowable parameter sets at a time


– Test for the specific functionality
– Step control after the specific time point
• Display mode of automatic checking
– display[0]: event current under test
– display[1]: the time error occurs
– display[2]: expected value and actual value
– ...

8/91
Reusable Design - Test Bench
• Use Global Connector to configure desired test
Institute of Electronics, National Chiao Tung University

bench
– E.g.: bus topology of IEEE 1394
IP Core Design, Modeling and Verification

Device 0 Device 0

Device 3 Device 3

Device 1 Device 1

Device 2 Device 2

9/91
Traditional ASIC Design Flow
Specification development
Institute of Electronics, National Chiao Tung University

RTL code development

Functional verification
IP Core Design, Modeling and Verification

Synthesis

Timing verificaiton

Place and route

Prototype build and test

Deliver to system integration and software test

Hardware and software development are mostly serialized


" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 10/91
SoC Design Flow Characteristics
• Parallel, concurrent development of hardware and
Institute of Electronics, National Chiao Tung University

software
• Parallel verification and synthesis of modules
• Floorplanning and place-and-route included in the
IP Core Design, Modeling and Verification

synthesis process

11/91
Spiral SoC Design Flow
System Design and Verification
Physical Timing Hardware Software
Institute of Electronics, National Chiao Tung University

Physical Timing Hardware Software


Specification: Specification: Specification: Specification:
area, power, I/O timing, algorithm application
clock design frequency development prototype
IP Core Design, Modeling and Verification

& macro development


decomposition
Preliminary Block timing Block Application
floorplan specification selection/design prototype Time
testing
Updated Block synthesis Block verification Application
floorplans Updated development
Updated Top-level RTL Application
floorplan testing
Trial Top-level Top-level Application
placement synthesis verification testing

Final floorplan, place and route - Tapeout


Top-down, bottom-up, meet at the middle
" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 12/91
IP Core Macro Design Process
Block specification

DEVELOP functional specification


Institute of Electronics, National Chiao Tung University

Completed behavioral
DEVELOP behavioral model DEVELOP testbench model for HW/SW
cosimulation and test
development
TEST behavioral model
CERATE BEHAVIROAL MODEL
IP Core Design, Modeling and Verification

PARTITION design into subblocks

WRITE functional specification

WRITE technical specification


Perform these steps
DEVELOP timing constraints WRITE RTL DEVELOP testbench for each subblock
RUN Lint
SYNTHESIS SIMULATE

PERFORM power analysis MEASURE test coverage


Meets timing, power, & area requirements Coverage tool passes
PASSES - READY FOR INTEGRATION

" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 13/91
Macro Integration Process
Subblock 1 Subblock 1 Subblock 1
Institute of Electronics, National Chiao Tung University

DETERMINE configuration and


GENERATE top-level HDL
Top-level HDL
FUNCTIONAL RUN lint GENERATE
VERIFICATION synthesis scripts
IP Core Design, Modeling and Verification

with reference simulator


SYNTHESIZE
with reference library
DEVELOP and RUN
multiple configuration tests
Scan insertion, ATPG,
fault simulation

MEASURE
test coverage PERFORM final timing
and power analysis

READY FOR PRODUCTION

PRODUCTIZE as soft macro

PRODUCTIZE as hard macro


" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 14/91
Four Major Phases
• Design top-level macro
Institute of Electronics, National Chiao Tung University

– macro specification; behavior model


– macro partition
• Design each subblock
IP Core Design, Modeling and Verification

– specification and design


– testbench; timing, power check
• Integration subblocks
• Macro productization

15/91
Specification at Every Level
• Overview
Institute of Electronics, National Chiao Tung University

• Functional requirements
• Physical requirements
• Design requirements
IP Core Design, Modeling and Verification

• Block diagram
• Interface to external system
• Manufacturing test methodology
• Software model
• Software requirement
• Deliverables
• Verification
16/91
Top-Level Macro Design Flow
Macro specification
Institute of Electronics, National Chiao Tung University

DEVELOP detailed
technical specification
IP Core Design, Modeling and Verification

CODE behavioral model CODE testbench


C/Verilog/VHDL C/Verilog/VHDL/Vera/Specman Completed behavioral
model for HW/SW
cosimulation and test
development
TEST behavioral model

CERETE BEHAVIROAL MODEL

PARTITION
the block into subblocks

" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 17/91
Top-Level Macro Design
• Updated macro hardware specification
Institute of Electronics, National Chiao Tung University

– document
• Executable specification
– language description
IP Core Design, Modeling and Verification

– external signals, timing


– internal functions, timing
• Behavioral model
– SystemC, HDL
• Testbench
– test vector generation, model for under test unit,
monitoring and report
• Block partition
18/91
Subblock Design Flow

WRITE functional specification


Institute of Electronics, National Chiao Tung University

WRITE technical specification


IP Core Design, Modeling and Verification

DEVELOP timing constraints WRITE RTL DEVELOP testbench


RUN Lint

SYNTHESIS SIMULATE
Design Compiler Verilog/VHDL

PERFORM power analysis MEASURE testbench coverage


PowerCompiler/QuickPower VHDLCover/VeriSure/CoverMeter

Meets timing, power, & area requirements Coverage tool passes


PASSES - READY FOR INTEGRATION

" Source: Michael Keating and Pierrr Bricaud, Reuse Methodology Manual, 2nd ed. 1999. 19/91
Subblock Design
• Design elements
Institute of Electronics, National Chiao Tung University

– Specification
– Synthesis script
– Testbench
IP Core Design, Modeling and Verification

– Verification suite
– RTL that pass lint and synthesis

20/91
Linter
• Fast static RTL code checker
Institute of Electronics, National Chiao Tung University

– preprocessor of the synthesizer


– RTL purification
• syntax, semantics, simulation
IP Core Design, Modeling and Verification

– timing check
– testability checks
– reusability checks
• Shorten design cycle by avoiding lengthy iterations

21/91
Subblock Integration Flow
Subblock 1 Subblock 1 Subblock 1
Institute of Electronics, National Chiao Tung University

DETERMINE configuration and


GENERATE top-level HDL
Top-level HDL
RUN lint GENERATE
FUNCTIONAL
Verilint, top-level synthesis scripts
VERIFICATION
IP Core Design, Modeling and Verification

Verilog/VHDL simulator VHDLlint


SYNTHESIZE
ModelSim, VSS, VCS
with reference library
Design Compiler
Scan insertion, ATPG,
DEVELOP and RUN coverage analysis
multiple configuration tests Test Compiler, DFTAdvisor,
Verilog/VHDL simulator FastScan/FlexTest
ModelSim, VSS, VCS
PERFORM analysis
QuickPower, Power Compiler

READY FOR PRODUCTION

PRODUCTIZE as soft macro

PRODUCTIZE as hard macro


22/91
Subblock Integration
• Integration process is complete when
Institute of Electronics, National Chiao Tung University

– top-level RTL, synthesis script, testbench complete


– macro RTL passes all tests
– macro synthesizes with reference library and meets all
IP Core Design, Modeling and Verification

timing, power and area criteria


– macro RTL passes lint and manufacturing test
coverage

23/91
Macro Productization
From block integration

DEVELOP specification TRANSLATE SYNTHESIS to


Institute of Electronics, National Chiao Tung University

for prototype chip Verilog ↔ VHDL multiple technologies CREATE


user documents: e.g.,
user guide
DESIGN chip
Verification guide
REGRESSION TEST RUN Pre-sim Integration guide
SYNTHESIS chip on translated code on one technology Test guide
IP Core Design, Modeling and Verification

Scan insertion, ATPG


and coverage analysis RUN TESTS Formal Verification
on multiple simulators RTL vs. gates
FLOORPLAN

PLACE and ROUTE

VERIFY timing

FABRICATE

TEST chip in demo board Release

24/91
Soft Macro Production
• Produce the following components
Institute of Electronics, National Chiao Tung University

– Verilog version of the code, testbenches, and tests


– Supporting scripts for the design
• installation script
IP Core Design, Modeling and Verification

• synthesis script
– Documentation

25/91
Principles of RTL Coding Styles
• Readability
Institute of Electronics, National Chiao Tung University

• Simplicity
• Locality
• Portability
IP Core Design, Modeling and Verification

• Reusability
• Reconfigurability

26/91
Naming Conventions
• Lowercase letters for signal names
Institute of Electronics, National Chiao Tung University

• Uppercase letters for constants


• Case-insensitive naming
• Use clk for clocks, rst for resets
IP Core Design, Modeling and Verification

• Suffixes
– _n for active-low, _a for async, _z for tri-state, …
• Identical names for connected signals and ports
• Do not use HDL reserved words
• Consistency within group, division and corporation

27/91
File Header
• Should be included for all source files
Institute of Electronics, National Chiao Tung University

• Contents
– author information
– revision history
IP Core Design, Modeling and Verification

– purpose description
– available parameters
– reset scheme and clock domain
– critical timing and asynchronous interface
– test structures
• A corporation-wide standard template

28/91
Ports
• Ordering
Institute of Electronics, National Chiao Tung University

– one port per line with appropriate comments


– inputs first then output
– clocks, reset, enables, orator controls, address bus,
IP Core Design, Modeling and Verification

then data bus


• Mapping
– use named mapping instead of positional mapping

29/91
Coding Practices
• Little-endian for multi-bit bus
Institute of Electronics, National Chiao Tung University

• Operand sizes should match


• Expression in condition must be a 1-bit value
• Use parentheses in complex statements
IP Core Design, Modeling and Verification

• Do not assign signals don’t-case values


• Reset all storage elements

30/91
Portability
• Do not use hard-coded numbers
Institute of Electronics, National Chiao Tung University

• Avoid embedded synthesis scripts


• Use technology-independent libraries
• Avoid instantiating gates
IP Core Design, Modeling and Verification

31/91
Clocks and Resets
• Simple clocking is easier to understand, analyze,
Institute of Electronics, National Chiao Tung University

and maintain
• Avoid using both edges of the clock
– duty-cycle sensitive
IP Core Design, Modeling and Verification

– difficult DFT process


• Do not buffer clock and reset networks
• Avoid gated clock
– Avoid internally generated clocks and resets
• limited testability

32/91
Low Power (1/2)
• Memory
Institute of Electronics, National Chiao Tung University

– low-power memory circuit design


– parathion a large memory into several small blocks
– gray-coded interface
IP Core Design, Modeling and Verification

32KB

64KB

32KB

33/91
Low Power (2/2)
• Clock gating
Institute of Electronics, National Chiao Tung University

– 50% - 70% power consumed in clock network reported


– gating the clock to an entire block
– gating the clock to a register Block A
IP Core Design, Modeling and Verification

Clock generation
and gating
Block A

9 D Q
always @(posedge clk)
if (en) en
q <= q_nxt; clk

8
Assign clk1 = clk & en; D Q
always @(posedge clk1)
if (en)
q <= q_nxt; en
clk

34/91
Synchronicity
• Infer technology-independent registers
Institute of Electronics, National Chiao Tung University

– (positive) edge-triggered registers


• Avoid latches intentionally
– except for small memory and FIFO
IP Core Design, Modeling and Verification

• Avoid latches unintentionally


– avoid incomplete assignment in case statement
– use default assignments
– avoid incomplete if-then-else chain
• Avoid combinational feedback loops
– STA and ATPG problem

35/91
Combinational and Sequential Blocks
• Combinational block
Institute of Electronics, National Chiao Tung University

– use blocking assignments (= in Verilog)


– minimize signals required in sensitivity list
– assignment should be applied in topological order
IP Core Design, Modeling and Verification

• Sequential block
– use non-blocking assignments (<= in Verilog)
– avoid race problems in simulation
• Comb./Seq. Logic should be separated

36/91
Coding for Synthesis (1/2)
• Specify complete but no redundant sensitivity lists
Institute of Electronics, National Chiao Tung University

– simulation coherence
– simulation speed
• If-then-else often infers a cascaded encoder
IP Core Design, Modeling and Verification

– inputs signals with different arrival time


• Case infers a single-level MUX
– case is better if priority encoding is not required
– case is generally simulated faster than if-then-else
• Conditional assignments
– infer a MUX, with slower simulation performance

37/91
Coding for Synthesis (2/2)
• FSM
Institute of Electronics, National Chiao Tung University

– partition FSM and non-FSM logic


– partition combinational part and sequential part
– use parameter to define names of the state vector
IP Core Design, Modeling and Verification

– assign a default (reset) state


• No # delay statements
• Use full_case and parallel_case judiciously
• Explicitly declare wires
• Avoid glue logic at the top-level
• Avoid expressions in port connections

38/91
Partitioning (1/2)
• Register all outputs
Institute of Electronics, National Chiao Tung University

– make output drive strengths and input delay predictable


– ease time budgeting and constraints
• Keep related logic together
IP Core Design, Modeling and Verification

– improve synthesis quality


• Partition logic with different design goals
• Avoid asynchronous logic
– technology dependent
– more difficult to ensure correct functionality and timing
– as small as possible and isolation
• Keep sharable resources in the same block
39/91
Partitioning (2/2)
• Avoid timing exception
Institute of Electronics, National Chiao Tung University

– point-to-point,false path, multi-cycle path


• Chip-level partitioning
– level 1: I/O pad ring only
IP Core Design, Modeling and Verification

– level 2: clock generation, analog, memory, JTAG


– level 3: digital core

TOP

Clock PADs
Generation
Core Logic
JTAG
MIDDLE

40/91
Coding for DFT
• Avoid tri-state buses
Institute of Electronics, National Chiao Tung University

– bus contention, bus floating


• Avoid internally generated clocks and resets
• Scan support logic for gated clocks
IP Core Design, Modeling and Verification

• Clock and set/reset should be fully externally


controllable under the test mode

41/91
Outline
• IP Core Designs
Institute of Electronics, National Chiao Tung University

• IP Core Verification
• IP Core Modeling and Deliverables
• System-Level Verification
IP Core Design, Modeling and Verification

42/91
IP Core Verification
• To ensure the IP macro is 100 percent correct in
Institute of Electronics, National Chiao Tung University

its functionality and timing.


• Testbench and test suites must be reusable by
other teams and compatible with verification tools
IP Core Design, Modeling and Verification

43/91
Verification Plan (1/2)
• Develop the verification environment
Institute of Electronics, National Chiao Tung University

– the set of testbench components such as bus functional


models, bus monitors, memory models and the
structural interconnect of such components with the
IP Core Design, Modeling and Verification

DUT
• The verification plan include
– a description of the test strategy, both at the block and
the top level
– a description of the simulation environment, including a
block diagram
– a list of testbench components
– a list of required verification tools, including simulators
and testbench creation tools
44/91
Verification Plan (2/2)
– a list of specific tests, along with the objective and
Institute of Electronics, National Chiao Tung University

estimated size of each


– an analysis of the key specification of the IP and
identification of which tests verify each specification
IP Core Design, Modeling and Verification

– a specification of what functionality of the IP will be


verified at the block level, and what will be verified at
the IP level
– a specification of the target code coverage for each
block and for the top-level IP
– a description of the regression test environment and
regression procedure

45/91
Verification Strategy
• Macro verification: 3 phases
Institute of Electronics, National Chiao Tung University

– verification of individual subblocks


– macro verification
– prototyping
IP Core Design, Modeling and Verification

• Basic types of verification tests include


– compliance test
• PCI interface, IEEE 1394
• complies with the specification
– corner case test
– random test
– real code test
– regression test

46/91
Verification Tools
• Simulation
Institute of Electronics, National Chiao Tung University

• Testbench automation tools


• Code coverage tools
• Hardware modeling
IP Core Design, Modeling and Verification

• Emulation
• Prototyping

47/91
Verification Support
• Protocol Checker
Institute of Electronics, National Chiao Tung University

– Monitor the transactions on an interface and check for


any invalid operation
• Embedded in the test bench
• Embedded in the design
IP Core Design, Modeling and Verification

– Error and/or warning messing of bus protocol


• Expected results checker
– Embedded in the test bench
– Checks the results of a simulation against a previously
specified, expected response file.
• Performance monitor
– Number of transfers, idle cycles...

48/91
Testbench Design
• The testbench design differs depending on the
Institute of Electronics, National Chiao Tung University

function of the macro


– microprocessor macro, test program,
– bus-interface macro, use bus functional models and
IP Core Design, Modeling and Verification

bus monitors
• Subblock testbench

Output Interface
Input Interface

Input Output
Transaction Transaction
Generator Checker

49/91
Macro Testbench
Application
Software
Institute of Electronics, National Chiao Tung University

Drivers
IP Core Design, Modeling and Verification

HW/SW cosim
Environment

Translator

Application
PCI Bus
Bus
Monitor
Monitor

PCI Bus Application Bus


PCI Macro
Functional Model Functional Model

50/91
Bus Functional Models (BFM)
• To model the bus transactions on the bus, each read
Institute of Electronics, National Chiao Tung University

and write transaction is specified by the test


developer.
• BFM is written is RTL, C/C++, or testbench
IP Core Design, Modeling and Verification

automation tools and uses some form of command


language to create sequences of transaction on the
bus.
• BFM and monitor must be designed and coded with
the same care as the macro RTL, all are deliverables

51/91
Automated Response Checking
• Compare the output response with a reference
Institute of Electronics, National Chiao Tung University

design
8051 chip
IP Core Design, Modeling and Verification

Hardware Modeler
Stimulus Compare response

8051 macro
(RTL)

• Bus monitors and checkers


• On-the-Fly checker

52/91
Verification Suite Design
• Once built the testbench , we can develop a set of
Institute of Electronics, National Chiao Tung University

tests to verify the correct behavior of the macro


• Test sets
– functional testing
IP Core Design, Modeling and Verification

– corner case testing


– code coverage
– random testing

53/91
Outline
• IP Core Designs
Institute of Electronics, National Chiao Tung University

• IP Core Verification
• IP Core Modeling and Deliverables
• System-Level Verification
IP Core Design, Modeling and Verification

54/91
The Intent of Different Level of IP Model
• Design exploration at higher level
Institute of Electronics, National Chiao Tung University

– Import of top-level constraint and block architecture


– Hierarchical, complete system refinement
– Less time for validating system requirement
IP Core Design, Modeling and Verification

– More design space of algorithm and system


architecture
• Simple and efficient verification and simulation
– Functional verification
– Timing simulation/verification
– Separate internal and external (interface) verification
– Analysis: power and timing
• Verification support: e.g., monitor, checker...

55/91
General Modeling Concepts
• Interface model
Institute of Electronics, National Chiao Tung University

– Synonym: bus functional, interface behavioral


• Behavioral model
– Behavior = function with timing
IP Core Design, Modeling and Verification

Interface
– Abstract behavioral model out=AxB
M-Bus

– Detailed behavioral model Clock


Abstract
• Structural model Behavioral
Model

CS
B B W_En
Interface

Interface

Interface

Interface
20
S
out=AxB out=AxB Data_Bus
B B 16
Addr_Bus
Clock
Detailed
Interface Behavioral Structural
Behavioral
Model Model Model
Model
56/91
Issues of IP Modeling
• Attributes
Institute of Electronics, National Chiao Tung University

– What is the sufficient set of model attributes?


– How are these model attributes validated?
– How is the proper application of an abstract model
IP Core Design, Modeling and Verification

specified?
• Two important dimensions of time
– Model development time is labor intensive: model
reusability
– Simulation time depends upon strategy chosen for
mixed domain simulations

57/91
From Requirement to Delivery

Hierarchy Hierarchy
Institute of Electronics, National Chiao Tung University

Refinemenet Validaton

Customer Product
Needs System Vaildation "Pattern" Deliver
IP Core Design, Modeling and Verification

System Function System Function

Architecture Architecture
Verification
Behavioral Behavioral

RTL Test
Patern
Logical Netlist Logical Device
Layout
Wafer
Abstract Mask Real
Fab

58/91
Example: Hierarchical Design Refinement
Vertical refinement Horizontal refinement: Partition
Institute of Electronics, National Chiao Tung University

F1 F2 F3

F4 F5 F6 F1 F2 F3

F4 F5 F6
IP Core Design, Modeling and Verification

CPU MEM Co-P

F1 F2 F3
In 1 In 2 Out 1
F4 F5 F6

CPU MEM Co-P

In 1 In 2 Out 1

59/91
Example: Manage Size and Run-Time
Start at RTL
Institute of Electronics, National Chiao Tung University

RTL Coding RTL Test Synthesis P&R

Integration Test
IP Core Design, Modeling and Verification

Start at behavioral level

RTL Coding RTL Test Synthesis P&R

Behavioral Level Coding


Behavioral Level Test
Integration Test

60/91
IP Modeling
General Modeling Concept
Institute of Electronics, National Chiao Tung University

Primary Model Classes: Specialized Model Classes: Computational Model Classes:

Behavioral Model Performance Model Data Flow Graph Model

Functional Model Interface Model Other Models

Structural Model Hybrid Model


IP Core Design, Modeling and Verification

System Models Architecture Models Hardware Models Software Models


Executable Specification Token-based Performance Model Detailed-Behavioral Model Pseudo-Code
Mathematical-Equation
Abstract-Behavioral Model Register Transfer Level (RTL) Model High Level Language (HLL)
Model
Algorithm Model Data Flow Graph (DFG) Task Primitive Logic-Level Model Assembly code

Instruction Set Architecture (ISA) Model Gate-Level Model Micro-Code

Switch-Level Model Object Code

Circuit-Level Model

Precision Axis
Temporal Precision Axis
Data Precision Axis
Functional Precision Axis
Structural Precision Axis
Software Programming Precision Axis
61/91
CPU Model
• CPU model enable
– Estimate software performance
Institute of Electronics, National Chiao Tung University

– Analyze system trade offs


• CPU model
– Bus functional model
IP Core Design, Modeling and Verification

I/O Bus
Compile to transactions Bus functional Events Hardware
Application code
host processor model simulator

– Instruction set simulator (SMM)


• Instruction accurate
• Cycle accurate
– Virtual processor model (Cadence VCC technology)

62/91
ARM Modeling (1/4)
Efficiency
Concept
Institute of Electronics, National Chiao Tung University

System model
Instruction set simulators (ISS)
Co-verification model
IP Core Design, Modeling and Verification

Bus Interface model


Behavioral/RTL model
Design signoff models

Hardware modeling
Gate Level netlist model
Silicon Accuracy

63/91
ARM Modeling (2/4)
• System Model • Co-verification model
Institute of Electronics, National Chiao Tung University

– Provision of customized – Each ARM processor core


Software Debugger/ARMulator contains a co-verification
packages, suitable for dataflow simulator component and a
simulation environments. bus interface model
component
IP Core Design, Modeling and Verification

– Cadence Signal Processing


– Co-verification simulator:
Worksystem (SPW) and combines the properties of
Synopsys COSSAP Stream an advanced ISS with the
Driven Simulator bus cycle accurate pin
information capability
required to drive a hardware
simulator
– CoWare N2C Design
System, Synopsys Eaglei, to
name a few.

64/91
ARM Modeling (3/4)
• Bus interface models (BIM) • Design signoff models
Institute of Electronics, National Chiao Tung University

– Run a list of bus transactions – Full architectural


to stimulate simulated functionality and full timing
hardware under test accurate simulation
– Allowing the designer to – Accept process specific
IP Core Design, Modeling and Verification

concentrate on the hardware timing and back annotated


design without waiting for the timing
ARM control software to be – Used to ‘sign off’’ design
developed. before committing silicon
– Generated using ModelGen – Be compiled 'C' code which
enables protection of the
inherent IP and superior
simulation execution speed
over pure HDL models
– Generated using ModelGen

65/91
ARM Modeling (4/4)
• Hardware Modeling • Fault grading netlist
Institute of Electronics, National Chiao Tung University

– Real chip-based products, – Full custom marcocells


based on real silicon yields models suitable for
– For logic and fault hardware accelerated fault
simulation grading, system simulation
IP Core Design, Modeling and Verification

– Synopsys ModelSource and emulation


hardware modeling systems – Emulator: IKOS, Mentor
Graphics and Quickturn;
Simulation: IKOS

66/91
Intent of ModelGen
• Key requirements for ARM’s modeling
Institute of Electronics, National Chiao Tung University

environment:
– Deliver highly secure models
– Minimize time spent creating, porting and re-verifying
IP Core Design, Modeling and Verification

models
– Support mixed-source languages—HDL, C and full
custom modeling
– Support multiple design and verification environments
– Enable efficient simulation
– Provide a timing annotation solution that does not
compromise IP security

67/91
“ModelGen” Timing Shell
• Overview:
Institute of Electronics, National Chiao Tung University

– Black-box model
• Obscured IP
ModelGen Source
– User supplied timing (MGS)
IP Core Design, Modeling and Verification

(SDF)
– Single model
• Easily verifiable
– Exported State
– Programmer model
• Nine-value Logic/Full
– Supports checkpointing

68/91
Example of Model Generation Flow
Institute of Electronics, National Chiao Tung University
IP Core Design, Modeling and Verification

Synopsys VMC/VhMC based model generation flow

VMC: Verilog Model Compiler, VhMC: VHDL Model Compiler 69/91


Behavioral Model for A/MS
• Describes the functionality and performance of a VC block
Institute of Electronics, National Chiao Tung University

without providing actual detailed implementation.


• Needed for system designers to determine the possibility
of implementing the system architecture
IP Core Design, Modeling and Verification

• It is a kind of abstract behavioral model


Bounds of actual behavioral
Actual behavioral
Signal Signal

Frequency Frequency
Behavioral Model Block Detail Model
70/91
Functional/Timing Digital Simulation Model
• Used to tie in functional verification and timing simulation
Institute of Electronics, National Chiao Tung University

with other parts of the system


• Describes the functionality and timing behavior of the
entire A/MS VC between its input and output pins.
IP Core Design, Modeling and Verification

• Pin accurate not meant to be synthesizable


• It is a kind of detailed-behavioral model
• Example of PLL: represent the timing relationship of
reference clock input vs. generate output clock.
– Model it by actually representing the structure of the PLL, or
– Model it as just a delay value based on a simple calculation from
some parameters.

71/91
Interface Model
• Describes the operation of a component with respect to its
Institute of Electronics, National Chiao Tung University

surrounding environment.
• The external connective points (e.g ports or parameters),
functional and timing details of the interface are provided
to show how the component exchanges information with
IP Core Design, Modeling and Verification

its environment.
• Also named as bus functional model and interface
behavioral model
• For A/MS VC
– Only the digital interface is described
– Analog inputs and outputs are not considered

72/91
Peripheral Interconnect Model
• Specifies the interconnection RCs for the peripheral
Institute of Electronics, National Chiao Tung University

interconnect between the physical I/O ports and the


internal gates of the VC
• Used to accurately calculate the interconnect delays and
output cell delays associated with the VC
IP Core Design, Modeling and Verification

• Used only for the digital interface of the A/MS VC

VC

Block
VC Internal VC
Model

Peripheral Peripheral
Interconnection Interconnection

73/91
Power Model
• Defines the power specification of the VC
Institute of Electronics, National Chiao Tung University

• Should be capable of representing both dynamic


power and static power
– Dynamic power may be due to capacitive loading or
IP Core Design, Modeling and Verification

short-circuit currents
– Static power may be due to state-dependent static
currents
• Required for all types of power analysis: average,
peak, RMS, etc.
• Abstract level
– Black/gray box, RTL source code and cell level

74/91
Basic Power Analysis Requirements
• Any power analysis should include effects caused
Institute of Electronics, National Chiao Tung University

by the following conditions and events:


– Switching activity on input ports, output ports, and
internal nodes
IP Core Design, Modeling and Verification

– State conditions on I/O ports and optionally internal


nodes
– Modes of operations
– Environmental conditions such as supply voltage and
external capacitive or resistive loading.

75/91
Physical Modeling
• Physical block implementation of hard, soft and firm VCs.
Institute of Electronics, National Chiao Tung University

• Two models for hard VCs


– Detailed model
• Description of the physical implementation of the VC at the polygon
level
IP Core Design, Modeling and Verification

• The preferred data format is GDSII 6.0.0


– Abstract model
• Contains enough information to enable floorplanning, placement, and
routing of the system level chip
– Footprint
– Interface pin/port list, shape(s), and usage
– Routing obstructions within the VC
– Power and ground connections
– Signature
• The preferred data format is the MACRO section of VC LEF 5.1

76/91
Deliverables
• Deliverables in different processes
Institute of Electronics, National Chiao Tung University

– VC transfer process
• To find, evaluate and deliver VC
– VC Integration process
IP Core Design, Modeling and Verification

• Different abstract-level models


• Comprehensive documentation
– Application notes, known bugs, system-level verification
and testing strategy, installation guides and scripts
• VC delivery specifications
– Nomenclature/Taxonomy, formats, attributes, and
structure for of VC design data and documentation
– Encryption, archive format, directory structure, etc.

77/91
RMM Soft Macro Deliverables
– Product files
• Synthesizable source code
Institute of Electronics, National Chiao Tung University

• Application notes with HDL design example


• Synthesis scripts & timing constraints
• Scripts for scan insertion and ATPG
• Reference library
• Installation scripts
IP Core Design, Modeling and Verification

– Verification files
• Bus functional model/monitors used in testbench
• Testbench files including representative verification tests
– Documentation
• User guide/Functional specification
• Datasheet
– System integration files/tools
• Cycle-based/emulation models as appropriate for macro and/or its
testbenches and BFMs
• Compilers, debuggers, real-time operating systems and software
drivers for programmable processor IP

" Source from OpenMORE Assessment Program 78/91


RMM Hard Macro Deliverables
– Product files
Institute of Electronics, National Chiao Tung University

• Installation scripts
– Documentation
• User guide/functional specification
IP Core Design, Modeling and Verification

• Datasheet
• Documentation contains version of library used and tools used
– System integration files /tools
• ISA and/or behavioral model
• Bus functional model
• Cycle-based/emulation models as appropriate for macro and/or
its testbenches and BFMs
• Compilers, debuggers, real-time operating systems and
software drivers for programmable processor IP

79/91
OpenMORE
• Open Measure of Reuse Excellence (Open
Institute of Electronics, National Chiao Tung University

MORE)
– A collaboration between Mentor Graphics and
Synopsys
IP Core Design, Modeling and Verification

– Based on Reuse Methodology Manual (RMM)


– IP providers use OpenMORE for self-evaluation
– Designers can ensure that each portion of a design is
workable and reusable
– Help the IP industry move to a higher quality level
– Supported by industry groups - VSIA,VCX, RAPID and
Design and Reuse

80/91
Motorola's SRS
• Semiconductor Reuse Standards (SRS)
Institute of Electronics, National Chiao Tung University

– An efficient design methodology that will enable rapid and


effective plug-and-play integration of reusable silicon IP into
system-on-a-chip solutions.
IP Core Design, Modeling and Verification

• Current four standards in SRS V2.0


– IP/VC Block Deliverables
• Data format of deliverables of soft, firm and hard core in different
phases
– 1st phase: deliverables required for instantiation and verification
– 2nd phase: deliverables required for backend-related views
– 3rd phase: deliverables required for test aspects
• Directory structure and naming convention of PC/VC deliverables

81/91
Motorola's SRS
• Current four standards in SRS V2.0
Institute of Electronics, National Chiao Tung University

– IP Interface (IPI)
• Colored line standard and signal definition
• Bus Interface operation
– Verilog HDL Coding
IP Core Design, Modeling and Verification

• Coding style and module partition for test, synthesis and reuse
• Based on IEEE 1364.1 synthesizable Verilog subset,
Synopsys/Mentor RMM and Motorola's experience in direct design
– Documentation
• Defines the content and format of documents required for IP/VC such
as Processor Cores, Analog/Mixed-Signal etc.
• Document types include Creation, Use, Integration, and Manufacturing
Test.
• Long-term goal: become as independent of software and platform

82/91
FPGA Reuse Manual
• Xilinx
– To facilitate design reuse in SoRC
Institute of Electronics, National Chiao Tung University

– Xilinx design reuse methodology for ASIC and FPGA designers


manual
• FPGA Supplement to Reuse Methodology Manual (RMM)
• Provides an overview of FPGA system level features
IP Core Design, Modeling and Verification

• Contains general RTL synthesis coding guidelines


– Xilinx FPGA reuse field guide
• Reuse concept from perspective of project
– Project specifications, project management organization, and
project verification and qualification
• Actel
– Actel HDL coding style guide
• Provides the preferred coding styles in both VHDL and Verilog for the
Actel architecture

83/91
Outline
• IP Core Designs
Institute of Electronics, National Chiao Tung University

• IP Core Verification
• IP Core Modeling and Deliverables
• System-Level Verification
IP Core Design, Modeling and Verification

84/91
System Verification
• It begins during system specification. The
Institute of Electronics, National Chiao Tung University

specification describes the basic test plan


including the criteria.
• As the system-level behavior model is developed,
IP Core Design, Modeling and Verification

a testbench and test suite should be developed to


verify the model.
• The system software should be developed and
tested using the behavior model.
• A rich set of test suites should be available for the
RTL and entire chip verification.

85/91
Verification Strategy
• Verify the individual IPs are functionally correct as
Institute of Electronics, National Chiao Tung University

stand-alone units
• Verify the interfaces between IPs are functional
correct, first in terms of the transaction type, and
IP Core Design, Modeling and Verification

then in terms of data content.


• Prototype the full chip and tun a set of complex
applications on the full chip.

86/91
IP-level Verification
• Use code coverage tools and a rigorous
Institute of Electronics, National Chiao Tung University

methodology to verify the RTL version of the IP.


• A physical prototype is built to prove silicon
verification of functional correctness.
IP Core Design, Modeling and Verification

87/91
Interface Verification
• Interface: address/data bus. Protocols
Institute of Electronics, National Chiao Tung University

– permitted sequence of control and data signals


– use a bus transaction monitor to check the transaction
IP Core Design, Modeling and Verification

Block 1 Block 2
Bus
Block 1 RTL Block 2 RTL Transaction
Interface Interface Monitor

Block 3 RTL Block 4 RTL


Interface Interface
Block 3 Block 4

• Use BFM to check the data read and write

88/91
Functional Verification (1/2)
• Two basic approaches
Institute of Electronics, National Chiao Tung University

– increase level of abstraction so that software simulators


running on workstations faster
– use specialized hardware for performing verification,
IP Core Design, Modeling and Verification

such as emulator or rapid prototyping


• Canonical SoC abstraction
– Full RTL model for IP cores
– behavior or ISA model for memory and processor
– bus functional model and monitor to generate and
check the transactions between IPs
– generate real application code for the processor and
run it on the simulation model
89/91
Functional Verification (2/2)
Bus Application
Monitor software/drivers/ Compiler
Institute of Electronics, National Chiao Tung University

RTOS

Processor Memory Controller Other


Memory
C/C++ C/C++ Peripherals
C/C++
IP Core Design, Modeling and Verification

RTL Interface RTL Interface (RTL)

I/O Interface (RTL) Data Transformation (RTL) I/O Interface (RTL)


CHIP

Communication bus Communication bus


Sequence
functional model functional model
generator/analyzer
(RTL) (RTL)

90/91
Rapid Prototyping
• FPGA prototyping
Institute of Electronics, National Chiao Tung University

– Aptix (FPGAs + programmable routing chips


• Emulation-based testing
– FPGA-based or processor-based
IP Core Design, Modeling and Verification

– QuickTurn and Mentor Graphics


• Real silicon prototyping
– faster and easier to build an actual chip and debug it
– design features in the real silicon chip
• good debug structure
• ability to selectively reset the individual IP blocks
• ability to selectively disable various IP blocks to prevent bugs
from affecting operations of the system

91/91

You might also like