A Design Flow for the Development, Characterization, and Refinement of System Level Architectural Se...
Download
1 / 58

Douglas Densmore Dissertation Talk and DES/CHESS Seminar May 15 th , 2007 - PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on

A Design Flow for the Development, Characterization, and Refinement of System Level Architectural Services. Douglas Densmore Dissertation Talk and DES/CHESS Seminar May 15 th , 2007. Committee Prof. Alberto Sangiovanni-Vincentelli (EECS) - Chair Prof. Jan Rabaey (EECS)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Douglas Densmore Dissertation Talk and DES/CHESS Seminar May 15 th , 2007' - conroy


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

A Design Flow for the Development, Characterization, and Refinement of System Level Architectural Services

Douglas Densmore

Dissertation Talk and DES/CHESS Seminar

May 15th, 2007

Committee

Prof. Alberto Sangiovanni-Vincentelli (EECS) - Chair

Prof. Jan Rabaey (EECS)

Prof. Lee Schruben (IEOR)


Objective
Objective Refinement of System Level Architectural Services

  • To demonstrate that architecture service modeling in system level design (SLD) can allow abstraction and modularity while maintainingaccuracy and efficiency.

#1

#2

#3

Time to Market


Outline
Outline Refinement of System Level Architectural Services

  • Problem Statement

  • Approach

  • Contribution

  • Motivating Factors

  • Design Trends and EDA Growth

  • Software Solutions

  • Programmable Platforms

  • Naïve Approach

  • My Improved Approach


Motivating factors
Motivating Factors Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Factor 1: Heterogeneity

Year

Existing and Predicted First Integration of SoC Technologies with Standard CMOS Processes1

Intel's PXA270

Mypal A730 PDA (digital camera and a VGA-TFT display)

Courtesy:http://www.intel.com/design/embeddedpca/applicationsprocessors/302302.htm

Solution 1: Modularity

  • D. Edenfeld, et. al., 2003 Technology Roadmap for Semiconductors, IEEE Computer, January 2004.


Motivating factors1
Motivating Factors Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Factor 2: Complexity

Courtesy: 1999 International Technology Roadmap for Semiconductors (ITRS)

Solution 2: Abstraction


Motivating factors2
Motivating Factors Refinement of System Level Architectural Services

37% of new digital products were late to market! (Ivo Bolsens, CTO Xilinx)

Digital Consumer Devices

Set-Top Equipment

Automotive

Year late effectively ends chance of revenue!

50%+ revenue loss when nine months late.

Three months late still loses 15%+ of revenue.

Gartner DataQuest. Market Trends: ASIC and FPGA, Worldwide, 1Q05 Update edition, 2002-2008.

Courtesy: http://www.ibm.com

Problem Statement

Approach

Contribution

Factor 3: Time to Market

Solution 3: Accuracy and Efficiency

Challenge: Remain modular and abstract


Design trends and eda growth
Design Trends and EDA Growth Refinement of System Level Architectural Services

Ravi Krishnan. Future of Embedded Systems Technology. BCC Research, June 2005.

Richard Goering. ESL May Rescue EDA, Analysts Say. EE Times, June 2005.

Problem Statement

Approach

Contribution


Software tools solution
Software Tools Solution Refinement of System Level Architectural Services

Meta model language

Meta model

compiler

Front end

Abstract syntax trees

...

Back end3

Back endN

Back end1

Back end2

Simulator tool

Synthesis tool

Verification tool

Verification tool

Application Space

Application Instance

Platform

Mapping

System

Platform

(HW and SW)

Platform

Design-Space

Export

Platform Instance

Architectural Space

Problem Statement

Approach

Contribution

  • Platform Based Design1 is composed of three aspects:

  • Top Down Application Development

  • Platform Mapping

  • Bottom Up Design Space Exploration

  • Orthogolization of concerns2

    • Functionality and Architecture

    • Behavior and Performance Indices

    • Computation, Communication, and Coordination.

  • Metropolis Meta Modeling (MMM) language4 and compiler are the core components.

  • Backend tools provide various operations for manipulating designs and performing analysis.

Design Technology Improvements and Impact on Designer Productivity3

  • A. Sangiovanni-Vincentelli, Defining Platform-based Design, EE Design, March 5, 2002.

  • K. Keutzer, Jan Rabaey, et al, System Level Design: Orthogonalization of Concerns and Platform-Based Design, IEEE Transactions on Computer-Aided Design, Vol. 19, No. 12, December 2000.

  • 2004 International Technology Roadmap for Semiconductors (ITRS).

  • F. Balarin, et al, Metropolis: an Integrated Electronic System Design Environment, IEEE Computer, Vol. 36, No. 4, April, 2003.


Programmable platforms
Programmable Platforms Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

What devices should the tools target? Programmable Platforms

What?

Why?

A system for implementing an electronic design. Distinguished by its ability to be programmed regarding its functionality.

One set of models represent a very large design space of individual instantiations.

At extremes:

Software Programmable – GPPs, DSPs

Bit Programmable – FPGAs, CPLDs

Platform FPGAs – FPGA Fabric & Embedded Computation Elements

Strengths:

Rapid Time-to-Market

Versatile, Flexible (increase product lifespan)

In-Field Upgradeability

Performance: 2-100X compared to GPPs

Weakness:

Performance: 2-6x slower than ASIC

Power: 13x compared to ASICs

Next “digital wave” will require programmable devices.1

Courtesy: K.Keuzter

  • Tsugio Makimoto, Paradigm Shift in the Electronics Industry, UCB, March 2005.


Programmable platform focus
Programmable Platform Focus Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

What do MY system level models need to capture?

K. Bondalapati, V. Prasanna, Reconfigurable Computing Systems, USC

IBM’s CoreConnect Architecture

Xilinx Virtex II

XC2VP30

MicroBlaze

Xilinx Virtex II ML310 Board

PowerPC

P. Schaumont, et al, A Quick Safari Through the Reconfigurable Jungle, DAC, June 2001.


Na ve approach
Naïve Approach Refinement of System Level Architectural Services

Architecture Model

Estimated

n

Abstract

o

Performance

i

I

t

a

Data

l

m

Modular

u

m

p

·

Datasheets

i

SLD Tools

S

l

·

Expertise

e

m

Manual

e

Bridge the Gap

!!

Disconnected

n

t

C

Model

Inaccurate

!

a

t

2

.

Synthesis

i

o

Manual

n

w

RTL

Golden

o

G

l

F

Model

a

l

o

p

o

Lengthy Feedback

!

T

c

i

t

a

m

o

t

u

Implementation

A

e

Platform

l

b

Inefficient

i

x

e

Miss

Time to Market

!

l

f

n

I

Problem Statement

Approach

Contribution

1

.

Design Space Exploration


My improved approach
My Improved Approach Refinement of System Level Architectural Services

Abstract

Refined

Problem Statement

Approach

Contribution

Functional level blocks of programmable components

Technique 1: Modeling style and characterization for programmable platforms

Real

Performance

Data

Estimated

Performance

Data

Abstract

Modular

SLD

From characterization flow

Narrow the Gap

Actual

Programmable

Platform Description

New approach has improved accuracy and efficiency by relating programmable devices and their tool flow with SLD (Metropolis). Retains modularity and abstraction.

Technique 2: Refinement Verification

Formal Checking

Methods

Manual

Informal

Correct!!


Approach statement
Approach Statement Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Problem:

SLD of architecture service models potentially is inaccurate and inefficient.

My Approach:

A PBD approach to Architecture Service Modeling which allows modularity and abstraction. By relating service models to:

  • programmable platforms,

  • platform characterization,

  • and refinement verification,

they will retain accuracy and efficiency.


Outline revisited
Outline Revisited Refinement of System Level Architectural Services

  • Problem Statement

  • Approach

  • Contribution

  • My Improved Approach

  • Approach Statement

  • Architecture Service Descriptions

  • Metropolis Overview

  • Programmable Architecture Service Modeling

  • Programmable Platform Characterization

  • Example of Techniques

Focus:Modularity


Architecture service taxonomy
Architecture Service Taxonomy Refinement of System Level Architectural Services

Add

DCT

CPU

C

F

C

F

C

F

Multi

FFT

Bus

C

F

C

F

C

F

Problem Statement

Approach

Contribution

Services are library elements, <F, C> where F is a set of interface functions (capabilities) and C is a set of cost models.

Single Component, Single Interface (SCSI) – One provided interface and one simple cost model

General

Purpose

Processor

Xilinx Virtex II Pro

Multiple Component, Multiple Interface (MCMI) – Two or more provided interfaces, zero or more internal interfaces, one or more simple cost functions, and zero or more complex cost functions.

Abstract

Multiple Component, Single Interface (MCSI) – One provided interface, one or more internal interfaces, and one or more complex cost functions.

Services also classified as active or passive.


Service based arch styles
Service Based Arch. Styles Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Assemble collections of services to provide larger sets of capabilities and cost functions.

Branching Style – Allows for the usage of all types of services

Ring Style – Allows for the usage of Single Interface (SI) services only

MCMI

Both Styles – Allow for the usage of active/passive and single/multiple component services.

Hierarchy – Each style can be abstracted into composite services.


Metropolis objects
Metropolis Objects Refinement of System Level Architectural Services

Proc1

P1

P2

Media1

I1

I2

QM1

Problem Statement

Approach

Contribution

  • Metropolis elements adhere to a “separation of concerns” ideology.

  • Processes (Computation)

Active Objects

Sequential Executing Thread

  • Media (Communication)

Passive Objects

Implement Interface Services

  • Quantity Managers (Coordination)

Schedule access to resources and quantities


Metro netlists and events
Metro. Netlists and Events Refinement of System Level Architectural Services

QM1

Problem Statement

Approach

Contribution

  • Metropolis Architectures are created via two netlists:

  • Scheduled – generate events1 for services in the scheduled netlist.

  • Scheduling – allow these events access to the services and annotateevents with quantities.

Scheduled Netlist

Scheduling Netlist

Proc1

Proc2

P1

P2

Global

Time

I1

Media1

I2

  • E. Lee and A. Sangiovanni-Vincentelli, A Unified Framework for Comparing Models of Computation, IEEE Trans. on Computer Aided Design of Integrated Circuits and Systems, Vol. 17, N. 12, pg. 1217-1229, December 1998


Services in design flow
Services in Design Flow Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Metropolis Media


Programmable arch modeling
Programmable Arch. Modeling Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

  • Computation Services

  • Communication Services

  • Other Services

Services are organized by orthogonal aspects of the system. All services created here are XCMI with more than two provided interfaces each.

Leverage function level granularity; 1-to-1 model/IP correspondence

  • Transaction Level

  • IP Parameters

  • I/O Interfaces

PPC405

MicroBlaze

SynthMaster

SynthSlave

Computation Interfaces

Read (addr, offset, cnt, size), Write(addr, offset, cnt, size),

Execute (operation, complexity)

Processor

Local

Bus

(PLB)

On-Chip

Peripheral

Bus

(OPB)

Communication Interfaces

addrTransfer(target, master)

addrReq(base, offset, transType, device)

addrAck(device)

dataTransfer(device, readSeq, writeSeq)

dataAck(device)

BRAM

Mapping

Process

OPB/PLB Bridge

Task Before Mapping

Read (addr, offset, cnt, size)

Task After Mapping

Read (0x34, 8, 10, 4)


Sample metropolis service
Sample Metropolis Service Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Each service profiled manually and given a set of cost models

Non-Ideal


Programmable arch modeling1
Programmable Arch. Modeling Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

  • Coordination Services

PPC Sched

MicroBlaze

Sched

PLB Sched

OPB Sched

BRAM Sched

General Sched

  • PostCond()

  • Augment event with information

  • (annotation). This is typically the

  • interaction with the quantity manager

  • Request (event e)

  • Adds event to pending

  • queue of requested events

  • Resolve()

  • Uses algorithm to select an

  • event from the pending queue

GTime


Sample metropolis qm
Sample Metropolis QM Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Each resolve() function is unique


Architecture extensions for preemption
Architecture Extensions for Preemption Refinement of System Level Architectural Services

4

.

Update the FSM to track the state of

the transaction

.

Event

Initial State

S

1

S

2

S

3

Transaction

(

i

.

e

.

Read

)

A

1

1

.

A transaction is

B

2

S1

introduced into the

architecture model

.

1

2

3

C

3

A

B

C

3

.

Dispatch the atomic transaction

(

AT

)

Trans

1

FSM

1

to the quantity manager

(

individual

2

.

Decoder transforms

events which make up the AT

).

the transaction into

atomic transactions

Trans

0

FSM

0

setMustDo

()

6

.

Use Stack data structure to store

SM

setMustNotDo

()

transactions and FSMs

5

.

Communication with preempted

processes through StateMedia

Problem Statement

Approach

Contribution

  • Some Services are naturally preempted

    • CPU context switch, Bus transactions

  • Notion of Atomic Transactions

    • Prior to dispatching events to a quantity manager via the request() method, decompose events in the scheduled netlist into non-preemptable chunks.

    • Maintain status with an FSM object (counter) and controller.

Process

Service

(

Media

)

(

Task

)

Decoder

(

Process)

Quantity Manager

FSM

.


Architecture extensions for mapping
Architecture Extensions for Mapping Refinement of System Level Architectural Services

Operations

Ability to perform

available

operations

Export information

service

from

Export information from

associated with

service

associated with

Task

Affinity

Task

Affinity

mapping process

mapping process

Execute

0

/

100

Execute

50

/

100

100

/

100

DCT

DCT

20

/

100

FFT

0

/

100

FFT

2

/

100

Dedicated HW

General Purpose

DCT

uProc

Only can perform DCT

!

Problem Statement

Approach

Contribution

  • Programmable platforms allow for both SW and HW implementations of a function.

  • Need to express which architecture components can provide which services and with what affinity.

public HashMap getCapabilityList()

Mapping

Mapping

Process

Process

(

Task

)

(

Task

)

HW DCT

uBlaze

(

Service

)

(

Service

)

Can perform multiple operations

Potential Mapping Strategies

Greedy

Best Average

Task Specific


Programmable arch modeling2
Programmable Arch. Modeling Refinement of System Level Architectural Services

1

.

Assemble Netlists

Structure Extractor

5

.

Gather information and

C

Mapping

T

o

parse into appropriate

Process

4

.

Extractor

o

n

MicroBlaze

MicroBlaze

p

tool format

n

Sched

Script Tasks

o

e

l

c

o

t

A

.

Identify parameters for

File for Programmable

OPB

Sched

i

OPB

g

o

y

service

.

For example MHZ

,

Platform Tool Flow

n

Scheduled

Netlist

Scheduling

Netlist

s

cache settings

,

etc

.

(

MHS

)

Top Level Netlist

Public netlist XlinxCCArch

Type

XilinxCCArchSched schedNetlist

;

XilinxCCArchScheduling schedulingNetlist

Parameters

SchedToQuantity

[]

_

stateMedia

Etc

B

.

Examine port

C

.

Examine address

D

.

Check port names

,

connections to

mapping for bus

,

I

/

O

,

instance names

,

etc for

determine topology

.

etc

.

instantiation

.

2

.

Provide Service Parameters

3

.

Simulate Model Decide on final topology

.

Problem Statement

Approach

Contribution

  • Compose scheduling and scheduled netlists in top level netlist.

  • Extract structure for programmable platform tool flow.

ModularModeling Style

Accurate & Efficient


Characterization in design flow
Characterization in Design Flow Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Work with Xilinx Research Labs

  • Douglas Densmore, Adam Donlin, A.Sangiovanni-Vincentelli, FPGA Architecture Characterization in System Level Design, Submitted to CODES 2005.

  • Adam Donlin and Douglas Densmore,Method and Apparatus for Precharacterizing Systems for Use in System Level Design of Integrated Circuits, Patent Pending.


Prog platform characterization
Prog. Platform Characterization Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Need to tie the model to actual implementation data!

1. Create template system description.

Process from Structure Extraction

2. Generate many permutations of the architecture using this template and run them through programmable platform tool flow.

3. Extract the desired performance information from the tool reports for database population.


Prog platform characterization1
Prog. Platform Characterization Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Create database ONCE prior to simulation and populate with independent (modular) information.

1. Data detailing performance based on physical implementation.

2. Data detailing the composition of communication transactions.

3. Data detailing the processing elements computation.

From Char Flow Shown

From Metro Model Design

From ISS for PPC


Characterized data organization
Characterized Data Organization Refinement of System Level Architectural Services

}

Index

System

1

System N

Method

}

4

.

2

ns

3

.

8

ns

Physical

4

ns

3

.

2

ns

Timing

ISS uProc

1

FFT

20

Cycles

}

Filter

35

Cycles

Computation

Timing

ISS uProc

2

FFT

10

Cycles

Filter

30

Cycles

}

Transaction

Timing

Problem Statement

Approach

Contribution

Metro

Characterizer

Model

Each system interface function characterized has an entry. These indices can be a hashed if appropriate.

?

?

Entries can share data or be independent.

?

?

NULL

?

Entries can have all, partial, or no information.

?

?

How is the data associated with each service interface function?


Prog platform characterization2
Prog. Platform Characterization Refinement of System Level Architectural Services

ModularCharacterization

Accurate & Efficient

Problem Statement

Approach

Contribution

Why can’t you just use a static estimation?

  • Design from rows 1, 3, and 5 of the table.

  • Three abstraction levels: 1, 3, and 10 cycle transactions.

  • Metropolis JPEG version: 112,500 write transactions for 3 MegaPixel, 24 bit color depth, 95% compressed image.

  • 19% difference between intuition and characterization.

  • As resource usage increases system frequency generally decreases.

  • Not linear nor monotonic.

  • 15% change is a speed grade for the devices.

Created database once prior to simulation.

PLB Write Transfer Performance Comparison


Modeling char review
Modeling Refinement of System Level Architectural Services & Char. Review

Problem Statement

Approach

Contribution

Branching Architecture Example

Scheduling Netlist

Task1

Task2

Task3

Task4

DEDICATED HW

DedHW Sched

MCMI

PPC

PPC Sched

Global

Time

MCMI

PLB

PLB Sched

MCMI

BRAM Sched

BRAM

SCSI

Scheduled Netlist

Characterizer

Media (scheduled)

Process

Enabled Event

Quantity

Quantity Manager

Disabled Event


Outline revisited1
Outline Revisited Refinement of System Level Architectural Services

  • Problem Statement

  • Approach

  • Contribution

  • Architecture Refinement Verification

  • Vertical Refinement

  • Horizontal Refinement

  • Surface Refinement

  • Depth Refinement

  • Design Flow Examples

  • Summary and Conclusions

Focus:Abstraction


Arch refinement verification
Arch. Refinement Verification Refinement of System Level Architectural Services

Architectures often involve hierarchy and multiple abstraction levels.

Limited if it is not possible to check if elements in hierarchy or less abstract components are implementations of their counterparts.

Asks “Can I substitute M1 for M2?”

Representing the internal structure of a component.

Recasting an architectural description in a new style.

Applying tools developed for one style to another style.

Problem Statement

Approach

Contribution

D. Garlan, Style-Based Refinement for Software Architectures, SIGSOFT 96, San Francisco, CA, pg. 72-75.


Refinement verification in design flow
Refinement Verification in Design Flow Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

  • Surface Refinement1

    • Interface Based

      • Control Flow Graph

    • Focus on introducing new behaviors (Reason 1)

  • Vertical Refinement1

  • Horizontal Refinement1

    • Event Based

      • Event Based Properties

    • Focus on abstraction & synthesis (Reasons 2 & 3)

  • Depth Refinement

  • Compositional Component Based

    • Labeled Transition Systems

  • Focus on reasons 1, 2, and 3

1. Douglas Densmore, Metropolis Architecture Refinement Styles and Methodology, University of California, Berkeley, UCB/ERL M04/36, 14 September 2004.


Vertical refinement
Vertical Refinement Refinement of System Level Architectural Services

Mapping

Process

Rtos

PPC405

Cache

PLB

BRAM

Problem Statement

Approach

Contribution

Rtos Sched

Mapping

Process

  • Definition: A manipulation to the scheduled netlist structure to introduce/remove the number or origin of events as seen by the scheduling netlist.

Cache Sched

Sequential

New

origins and

amounts

of events

scheduled

and

annotated

PPC Sched

PLB Sched

Concurrent

BRAM Sched

Scheduling Netlist

Scheduled Netlist


Horizontal refinement
Horizontal Refinement Refinement of System Level Architectural Services

Mapping

Process

Control

Thread

Rtos

PPC405

Arb

Cache

PLB

BRAM

Problem Statement

Approach

Contribution

Rtos Sched

Mapping

Process

PPC Sched

  • Definition: A manipulation of both the scheduled and scheduling netlist which changes the possible ordering of events as seen by the scheduling netlist.

PPC405

Cache Sched

Ordering

of event

requests

changed

PPC Sched

PLB Sched

BRAM Sched

Scheduling Netlist

Scheduled Netlist

*Contains all possible orderings if abstract enough


Event based properties
Event Based Properties Refinement of System Level Architectural Services

Properties expressed as event sequences as seen by the scheduling netlist.

Problem Statement

Approach

Contribution

E1 (CPUExe)

E2 (CPUExe)

E3 (CPUExe)

E4(CPURead)

Resource Utilization

Latency


Macro and microproperties
Macro and MicroProperties Refinement of System Level Architectural Services

Data Precision

(

DP

)

No Overflow

(

NO

)

Level

3

Sufficient Bits

(

SB

)

1

2

Write Access

(

WA

)

Sufficient Space

(

SS

)

1

0

Data Consistency

(

DC

)

Level

2

Read Access

(

RA

)

Data Valid

(

DV

)

1

0

Data Coherency

(

DCo

)

Level

1

Snoop Complete

(

SC

)

0

Problem Statement

Approach

Contribution

MicroProperty - The combination of one or more attributes (or quantities) and an event relation defined with these attributes.

MacroProperty – A property which implies a set of MicroProperties. Defined by the property which ensures the other’s adherence. The satisfaction (i.e. the property holds or is true) of the MacroProperty ensures all MicroProperties covered by this MacroProperty are also satisfied.


Event petri net
Event Petri Net Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Model Event Petri Net – One transition set which represents events of interest, tEN. Transitions also are used to indicated interface functions.

Link the two event petri nets together such that select tENs feed connection transitions, tCN, which produce the needed tokens for the property EPN.

Two Petri Nets – One for the service model and one for the events of interest.

Property Event Petri Net – Initial marking vector is empty. One place per Macroproperty, p<prop>. Created such that in order to create a token in each MacroProperty place, all transitions must fire once and only once.


Surface refinement def
Surface Refinement Def. Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

  • Defined as in Hierarchical Verification1

    • Model: An object which can generate a set of finite sequences of behaviors, B

    • Trace: a B

    • Given a model X and a model Y, X refines the model, denoted X < Y if given a trace a of X then the projection a[ObsY] is a trace of Y.

    • Two models are trace equivalent, X  Y if X < Y and Y < X.

  • The answer to the refinement problem (X,Y) is YES if X refines Y, otherwise NO

TraceM – Trace in Metropolis = a finite set of function calls to media via interfaces

1. T.Henzinger, S.Qadeer, S.K. Rajamani, “You Assume, We Guarantee: Methodology and Case Studies”, 10th International Conference on Computer Aided Verification (CAV), Lecture Notes in Computer Science 1427, Springer-Verlag, 1998, p.440-451.


Control flow graph
Control Flow Graph Refinement of System Level Architectural Services

Hypothetical Automaton for X variable

1

2

3

X

=

0

X

=

1

X

=

2

Control Location

1

1

Group Node Type

:

ProcessDeclNode

Graph for Model

Initial Control Location

X

=

0

Control Location

2

2

Group Node Type

:

LoopNode

while loop

X

<

2

X

>

=

2

Control Location

3

Control Location

7

Group Node Type

:

3

7

Group Node Type

:

ThisPortAccessNode

ThisPortAccessNode

Port

1

.

callRead

()+

Port

2

.

callWrite

()+

Control Location

4

Control Location

8

4

8

Group Node Type

:

None

Group Node Type

:

None

Ending of basic block

Ending of basic block

Port

1

.

callRead

()

-

Control Location

5

Port

2

.

callWrite

()

-

5

Group Node Type

:

Collection

of Variable Nodes

X

++(+)

Control Location

9

9

Control Location

6

Group Node Type

:

None

6

Group Node Type

:

Variable

Sink State

Node

(

collection

)

-

End

X

++(

-

)

10

Control Location

10

Group Node Type

:

None

Bookend of LoopNode

Problem Statement

Approach

Contribution

  • Defined much like*

  • Tuple <Q, qo, X, Op, >

    • Q – Control Locations

    • qo – initial CL

    • X – set of variables

    • Op – function calls to media, basic block start and end

    •  - transition relation

//sample code

Process example{

port Read port1;

port Write port2;

Void thread(){

int x = 0;

while (x < 2){

port1.callRead();

x++;}

port2.callWrite();

}}

*”Temporal Safety

Proofs for Systems Code”,

Henzinger et al.


Surface refinement domains
Surface Refinement Domains Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

<C, P, OP>


Surface refinement example
Surface Refinement Example Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Trace containment check for single threaded processes

  • Douglas Densmore, Sanjay Rekhi, A. Sangiovanni-Vincentelli, MicroArchitecture Development via Successive Platform Refinement, Design Automation and Test Europe (DATE), Paris France, 2004.


Surface refinement flow
Surface Refinement Flow Refinement of System Level Architectural Services

Metropolis Model

(.

mmm

)

1

3

2

CFG Backend

Reactive Module

Visual

of CFG

(

X

)

(

automatic

)

Representation

Witness

(

for debugging

)

Module

(

W

)

4

Kiss file of CFA

3

a

£

Answer to X

Y

SIS

Edit and Parallel

FORTE

4

c

Composition

state

_

assign script

(

automatic

)

(

manual

)

4

a

Mode

.

exe file

X

||

W

BLIF file

3

b

4

b

MOCHA

Manual Edits to BLIF and

NEXLIF

2

EXE

Answer

£

to X

Y

CFA

(

Y

)

developed in

BLIF file developed in

previous iteration

previous iteration

Problem Statement

Approach

Contribution

Three primary branches:

1. Visual representation for debugging

2. CFG conversation to a reactive module. Works with the MOCHA tool flow. Requires manual augmentation of a witness module since Y has private variables.

3. CFG conversation to a KISS file. Works with the SIS and Forte tool flows. Requires manual edits to BLIF to EXLIF.


Depth refinement lts
Depth Refinement - LTS Refinement of System Level Architectural Services

Service

Write

Read

Read2

Write2

Problem Statement

Approach

Contribution

  • Depth Refinement – Want to make inter-component structural changes.

  • Definition: A Labeled Transition System (LTS) is a

    tuple <Q, Q0, E, T, l> where:

    • Q is a set of states,

    • Q0  Q is a set of initial states,

    • E is a finite set of transition labels or actions,

    • T  Q x E x Q is a labeled transition relation, and

    • l : is an interpretation of each state on system variables.

  • But in LTS there is no notion of input signals

    • When we compose LTS, a transition can be triggered when another LTS is in a given state.

Olga Kouchnarenko and Arnaud Lanoix. Refinement and Verification of Synchronized

Component-Based Systems. In FME 2003: Formal Methods, Lecture Notes in Computer Science,

volume 2805/2003, pages 341–358. Springer Berlin / Heidelberg, 2003


Refinement rule 1
Refinement Rule 1 Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Strict transition refinement

  • If there is a transition in the refined LTS from one state to another, then there must be the same transition in the abstract

  • Note: The two transitions must have the same label!


Refinement rule 2
Refinement Rule 2 Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Stuttering transition refinement

  • If there is a new (tau) transition in the refinement LTS, then its beginning state and ending state must correspond to the same state in the abstract


Refinement rule 3
Refinement Rule 3 Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

Lack of τ-divergence

  • There are no new transitions in the refinement that go on forever


Refinement rule 4
Refinement Rule 4 Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

External non-determinism preservation

  • If there is a transition in the abstract and the corresponding refined state does not have any transition then

    • there must be another refined state that corresponds to the abstract

    • it must take a transition to another refined state and in the abstract must exist a state so that these two are glued together.


Depth ref design flow
Depth Ref. Design Flow Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

//Buffer Events (reads and writes)

//‘‘write1’’ event is enabled when the LTSs are in the following states

(write1) when

((prod = produce) /\ (buf = empty) /\ (con != consume)),

(write3) when

((prod = produce) /\ (buf = notempty) /\ (con != consume)),

(read1) when

((prod != produce) /\ (buf = notempty) /\ (con = consume)),

(read3) when

((prod != produce) /\ (buf = full) /\ (con = consume)),

//Producer Events

make when

(prod = wait),

stall when

(prod = produce),

//Consumer Events

get when

(con = wait),

stallC when

(con = consume)

Transition System

//Two state values

type SIGNAL = {consume, wait}

local con : SIGNAL

//Can only be in one state

Invariant

(con = consume) \/ (con = wait)

//Initial state

Initially (con = wait)

//Transistion to consume (‘‘get’’ event)

Transition get :

enable (con = wait) ;

assign con := consume

//Transition to wait (‘‘stallC’’ event)

Transition stallC :

enable (con = consume) ;

assign con := wait

  • Create a .fts file capturing the LTS for each component of the refined and abstract systems.

    • Define observable events, OE

    • Transaction labels correspond to OE

  • Define gluing invariants in .inv file.

((con = consume) <--> (conR = consume))

/\((con = wait) <--> ((conR = wait) \/ (conR = clean)))

3. Define synchronization between LTS in .sync file.


Example design
Example Design Refinement of System Level Architectural Services

JPEG Encoder Function Model (Block Level)

Structure

Extractor

Preprocessing

DCT

Mapping

Process

Quantization

Huffman

Mapping

Process

Mapping

Process

Mapping

Process

MicroBlaze

SynthMaster

On-Chip

Peripheral

Bus

(OPB)

SynthSlave

BRAM

BRAM

Problem Statement Approach Contribution

3. Assemble an architecture from library services or create your own services.

  • Select an application and understand its behavior.

Top Level Netlist

5. Extract a structural file from the top level netlist of the architecture created.

2. Create a Metropolis functional model which models this behavior.

4. Map the functionality to the architecture.

File for Xilinx EDK Tool Flow

IP Library


Example design cont
Example Design Cont. Refinement of System Level Architectural Services

Permutation 1

Permutation 2

Permutation N

Platform Characterization Tool (Xilinx EDK/ISE Tools)

Manual

Software Routines

int DCT (data){

Begin

calculate …

}

Hardware Routines

DCT1 = 10 Cycles

DCT2 =5 Cycles

FFT = 5 Cycles

Automatic

Manual

32 Bit Read = Ack, Addr, Data, Trans, Ack

Problem Statement

Approach

Contribution

1. Feed the captured structural file to the permutation generator.

File for Xilinx EDK Tool Flow

2. Feed the permutations to the Xilinx tools and extract the data.

3. Capture execution info for software and hardware services.

4. Provide transaction info for communication services.

Permutation Generator

ISS Info

Char

Data

Transaction

Info

Characterizer Database


Example design cont1
Example Design Cont. Refinement of System Level Architectural Services

JPEG Encoder Function Model (Block Level)

Execution time 100ms

Bus Cycles 4000

Ave Memory Occupancy 500KB

Preprocessing

DCT

Mapping

Process

Quantization

Huffman

Mapping

Process

Mapping

Process

Mapping

Process

MicroBlaze

On-Chip

Peripheral

Bus

(OPB)

BRAM

Concurrent

Vertical

Refinement

4. Re-simulate to see if your goals are met.

Verification

Tool

Execution time 200ms

Bus Cycles 1000

Ave Memory Occupancy

100KB

BRAM

BRAM

Yes?

No?

Problem Statement

Approach

Contribution

  • Backend Tool Process:

  • Abstract Syntax Tree (AST) retrieves

  • structure.

  • 2. Control Data Flow Graph - Surface

  • FORTE – Intel Tool

  • Reactive Models – UC Berkeley

  • 3. Event Traces – Refinement

  • Properties.

  • Vertical Refinement

  • Horizontal Refinement

1. Simulate the design and observe the performance.

SynthMaster

2. Refine design to meet performance requirements.

New Algorithm

SynthSlave

  • 3. Use Refinement Verification to check validity of design changes.

    • Vertical, or Horizontal

    • Depth, Surface

    • Refinement properties

Surface

ISS Info

Char

Data

Transaction

Info


Mjpeg encoding
MJPEG Encoding Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution


Other case studies
Other case studies Refinement of System Level Architectural Services

  • H.264 Deblocking Filter

    • 14 different mapping explored

    • Execution time analysis for computation, waiting, and communication operations.

    • Average differences from Metropolis simulation and actual implementation was 3.48%.

  • SPI-5 Packet Processing

    • 6 architecture models developed

    • Optimal FIFO length determined


Summary and conclusions
Summary and Conclusions Refinement of System Level Architectural Services

Problem Statement

Approach

Contribution

  • Heterogeneity Modularity

    • Functional block levelMetropolis models of programmable services.

      • Direct structural correspondence aidsaccuracy. Automatic structure extraction createsefficiency.

    • Independentcharacterization processof actual hardware implementations.

      • Shown to beaccurate. Independence createsefficiency.

  • Complexity Abstraction

    • Depth/Surface Refinementallows internal changes to the model.

      • Trace based formalismaccuracy. Automatic checkingefficiency.

    • Vertical/Horizontal Refinementallow structural changes to the model.

      • Event based formalismaccuracy. Refinement property encapsulationefficiency.


Thanks
Thanks Refinement of System Level Architectural Services

  • Questions?

  • Thanks

    • Metropolis Team: Yoshi Watanabe, Felice Balarin, Roberto Passerone, Abhijit Davare, Haibo Zeng, Qi Zhu, Guang Yang, Trevor Meyerowitz, Alessandro Pinto

    • Committee: Jan Rabaey, Alberto Sangiovanni-Vincentelli, John Wawrzynek, Lee Schruben

    • Industrial: Adam Donlin (Xilinx), Sanjay Rekhi (Cypress)


ad