Shaahin Hessabi Department of Computer Engineering Sharif University - - PowerPoint PPT Presentation

shaahin hessabi department of computer engineering sharif
SMART_READER_LITE
LIVE PREVIEW

Shaahin Hessabi Department of Computer Engineering Sharif University - - PowerPoint PPT Presentation

Shaahin Hessabi Department of Computer Engineering Sharif University of Technology D Design for Reuse i f R Design for reuse is an absolute necessity to: maintain productivity levels, keep the design time within reasonable


slide-1
SLIDE 1

Shaahin Hessabi Department of Computer Engineering Sharif University of Technology

slide-2
SLIDE 2

D i f R Design for Reuse

Design‐for‐reuse is an absolute necessity to:

maintain productivity levels, keep the design time within reasonable bounds.

Good designer

100 gates per day, or 30 lines of RTL code a day. 100K gate ASIC (a typical 1990s design) 100K gate ASIC (a typical 1990s design)

1000 designer‐days ‐> 5 person team for about a year

10 M gate ASIC design

g g

100,000 designer‐days ‐>500 persons for about a year

100 M gate SoC design

d i d f b t !

1,000,000 designer‐days ‐> 5,000 persons for about a year! or 50 person

team about 10 years!

Sharif University of Technology Designing Logic Cores 2

slide-3
SLIDE 3

Design for Reuse Requirements

d f l d

good functional documentation, good coding practices, carefully designed verification environments

thorough test suites,

b d il EDA l i

robust and versatile EDA tool scripts effective porting mechanism across various technology

libraries (for hard cores) libraries (for hard cores).

Sharif University of Technology Designing Logic Cores 3

slide-4
SLIDE 4

General Guidelines for Design Reuse Design Process for Soft and Firm Cores g Design Process for Hard Cores

Sharif University of Technology Designing Logic Cores 4

slide-5
SLIDE 5

General Guidelines for Design Reuse

h

Synchronous Design Memory and Mixed‐Signal Design On‐Chip Buses Clock Distribution Clear/Set/Reset Signals Deliverable Models

Sharif University of Technology Designing Logic Cores 5

slide-6
SLIDE 6

S h D i Synchronous Design

Use registers for synchronization in Use registers for synchronization in

core logic and its inputs and

  • utputs to manage core‐to‐core

p g interaction.

Creates a wrapper around a core.

b l

portability manufacturing test application

Avoid latches in random logic Avoid latches in random logic

Use them only in blocks such as FIFOs,

memories, and stacks

  • Avoid asynchronous loops, internal pulse generator circuits,

direct combinational paths from block inputs to outputs

Sharif University of Technology Designing Logic Cores 6

p p p

slide-7
SLIDE 7

Memory and Mixed‐Signal Design

Large memories: different parasitics at boundary

cells and a cell in the middle of an array.

Include rows and columns of dummy cells at the Include rows and columns of dummy cells at the

periphery of large memories

Make these rows and columns part of the built‐in self‐

( ) h h d repair (BISR) mechanism, to minimize area overhead.

most commonly used analog/mixed‐

i l i it d i S C PLL signal circuits used in SoC: PLLs, ADCs/DACs, and temperature sensors.

extremely sensitive to noise and extremely sensitive to noise and

technology parameters

place them at the corners

Sharif University of Technology Designing Logic Cores 7

slide-8
SLIDE 8

On‐Chip Buses

On‐chip buses and data transaction protocol must

be designed prior to the core selection process.

Core providers cannot envision all possible interfaces.

Parameterized interfaces should be used in core design.

FIFO b d i f fl ibl d il i h dli i d

FIFO‐based interfaces are flexible and versatile in handling varying data

rates between cores and the system buses

Organizations (VSI Alliance, …) develop on‐chip bus and

g ( , ) p p core interface standards/specifications.

support multiple masters, separate identity for data and control

i l f ll h d l i l l i b signals, fully synchronous and multiple cycle transactions, bus request‐and‐grant protocol

Sharif University of Technology Designing Logic Cores 8

slide-9
SLIDE 9

Clock Distribution

h ll b f l k d

Use the smallest number of clock domains. Isolate each clock in an independent domain. Use buffers at the clock boundary. Avoid metastability between clock domains interface Use synchronization method at the clock boundaries.

E.g., clock buffering and dual stage FFs or FIFOs at the clock

boundary boundary.

Distribute a low‐frequency chip‐level synchronization

clock when cores contain local PLLs. clock when cores contain local PLLs.

Each core’s local PLL should lock to this clock and generate

required frequency for the core.

Sharif University of Technology Designing Logic Cores 9

slide-10
SLIDE 10

Cl /S t/R t Si l Clear/Set/Reset Signals

Document all reset schemes for the entire design: Document all reset schemes for the entire design:

Synchronous/asynchronous, internal/external power‐on‐resets, any software reset schemes used,

y

does any functional block has locally generated resets, whether resets are synchronized with local clocks, …

Use synchronous reset if possible

avoids race conditions on reset, t ti ti

i l i diffi lt ith h t

static timing analysis difficult with asynchronous resets, designer has to evaluate the reset pulse width at every FF

to make sure it becomes inactive synchronously to clocks

y y

Sharif University of Technology Designing Logic Cores 10

slide-11
SLIDE 11

D li bl M d l Deliverable Models

Design reuse depends on quality of deliverable models: Design reuse depends on quality of deliverable models:

behavioral or instruction set architecture (ISA) model, bus functional model for system‐level verification,

y

fully functional model for timing and cycle‐based logic

simulation/emulation,

  • h

i l d i d l fl l i ti i d

physical design models: floor planning, timing, and area

Might be delivered in encrypted form to restrict piracy and

reverse engineering reverse engineering.

create a top‐level module and instantiate the core model inside it.

the top‐level module behaves as a wrapper and hides the whole netlist, floor

planning, and timing of the core

Sharif University of Technology Designing Logic Cores 11

slide-12
SLIDE 12

D li bl M d l (N d d U ) Deliverable Models (Need and Usage)

Sharif University of Technology Designing Logic Cores 12

slide-13
SLIDE 13

Design Process for Soft and Firm Cores

l

Design Flow Development Process for Soft/Firm Cores RTL Guidelines Soft/Firm Cores Deliverables

Sharif University of Technology Designing Logic Cores 13

slide-14
SLIDE 14

Design Flow

Design with a

conventional EDA RTL th i fl RTL synthesis flow.

Reusability

requirement requirement multiple configuration tests should be developed and run.

Sharif University of Technology Designing Logic Cores 14

slide-15
SLIDE 15

Development Process for Soft/Firm Cores

Required design specifications at every step in development Required design specifications at every step in development

process:

1. Functional (purpose and operation) p p p 2. Physical (packaging, area, power, technology libraries, …) 3. Design requirements (architecture and block diagrams with data fl ) flow) 4. Interface requirements to specify signal names and functions, timing diagrams, and DC/AC parameters g p 5. Test and debug (testing, DFT methodology, test vector generation method, fault grading, …) 6 S ft i t ( ft d i d d l f h d 6. Software requirements (software drivers and models for hardware blocks)

Sharif University of Technology Designing Logic Cores 15

slide-16
SLIDE 16

RTL Guidelines

RTL coding style determines:

g y

Portability Reusability Area and performance of the core after synthesis.

So, develop RTL code that is:

Simple and easy to understand, structured, uses simple constructs and consistent naming conventions uses simple constructs and consistent naming conventions Easy to verify and synthesize.

Consult Verilog/VHDL books for good coding guidelines.

Co su t e

  • g/

boo s o good cod g gu de es.

Sharif University of Technology Designing Logic Cores 16

slide-17
SLIDE 17

Soft/Firm Cores Deliverables

d f l

Product files

Synthesizable source code Application notes with HDL design example Application notes with HDL design example Synthesis scripts & timing constraints Scripts for scan insertion and ATPG

p

Reference library Installation scripts

Verification files

Bus functional model/monitors used in testbench

T b h fil i l di i ifi i

Testbench files including representative verification tests

Sharif University of Technology Designing Logic Cores 17

slide-18
SLIDE 18

S f /Fi C D li bl ( ’d) Soft/Firm Cores Deliverables(cont’d)

Documentation

User guide/Functional specification Datasheet Datasheet

System integration files/tools

Cycle‐based/emulation models as appropriate for macro and/or its Cycle based/emulation models as appropriate for macro and/or its

testbenches and BFMs

Compilers, debuggers, real‐time operating systems and software

d i f bl IP drivers for programmable processor IP

Additional for firm cores:

gate le el netlist description of the technolog librar timing gate‐level netlist, description of the technology library, timing

model, area, and power estimates.

Sharif University of Technology Designing Logic Cores 18

slide-19
SLIDE 19

Design Process for Hard Cores Clock and Reset Clock and Reset Porosity, Pin Placement, and Aspect Ratio

Sharif University of Technology Designing Logic Cores 19

slide-20
SLIDE 20

Cl k d R Clock and Reset

Implementation of clock and reset should be independent

  • f SoC clock and reset.

Since SoC‐level information not available at the time of core design.

Clock and reset require buffering and minimum wire

loading. Cl k t b il bl t t i f th

Clock must be available on an output pin of the core.

Used for synchronization with other SoC‐level on‐chip clocks.

Sharif University of Technology Designing Logic Cores 20

slide-21
SLIDE 21

Porosity, Pin Placement, and Aspect Ratio

During SoC‐level integration, often desirable to route over a

g g core or through a core.

Hard core should have porosity, i.e., some routing channels through

the core should be made available; or the core should be made available; or

limit number of metal layers in the core to 1‐2 less than the

maximum allowable by the process.

D li

bl f th h ld i l d bl k t id tif th

Deliverables for the core should include a blockage map to identify the

areas where SoC‐level routing may cause errors due to crosstalk, ….

Core pin placement affect SoC‐level floor plan and routing.

Large logic cores are normally placed on one corner of the SoC.

Vdd/Gnd pins should be placed on one or, at most, two sides rather than

distributing them along all four sides,

Also, signals that remain primary I/Os at SoC level; e.g. USB and PCI bus

Aspect ratios should be kept close to 1:1 or 1:2, for minimal

impact on SoC‐level floor plan impact on SoC‐level floor plan.

Sharif University of Technology Designing Logic Cores 21