Version D 0.2 Fall 2000 -...

RASSPReinventingElectronic

Design

Methodology

Architecture Infrastructure

ARPA Tri-Service

RASSP E&FRASSP E&FSCRA GT UVA RaytheonSCRA GT UVA Raytheon

UCinc EIT MMG ADLUCinc EIT MMG ADL

System-Level Modeling(KJH, with slides removed fromRASSP Module 9, vhdl_M.ppt)

Fall 2000RASSP Education & Facilitation

Version D 0.2


Design

Methodology


ARPA Tri-Service



RASSP Roadmap

System-level modelingSystem-level modeling

SYSTEMDEF.

FUNCTIONDESIGN

HW & SW

PART.

HWDESIGN

SWDESIGN

HWFAB

SWCODE

INTEG.& TEST

VIRTUAL PROTOTYPE

RASSP DESIGN LIBRARIES AND DATABASE

Primarilysoftware

Primarilyhardware

HW & SW CODESIGN

[Richards94]


Design

Methodology


ARPA Tri-Service



Module Goals

λ To provide motivation for the use of system-levelmodeling

λ To show how the use of system-level modelingcan improve design methodology

λ To detail the types of system-level modeling andwhat types of analysis can be done with each

λ To show how to incorporate system-levelmodeling into a design environment


Design

Methodology


ARPA Tri-Service



Introduction

λ Motivationµ Digital systems have become large and complex

θ Breadboard and prototypes are too costly fordemonstrating complex system performance

θ Need analysis and simulation of hardware andsoftware

µ There is a shift from structural to behavioral designµ Different models of the same system are used at

different stages and by different designers, resulting inθ Possibility of loss of informationθ Difficulties or misunderstandings caused by

inconsistencies between different modelsθ Need to use different tools for different models

µ Redesign of digital systems costs $ 5-10 billionsannually in US alone


Design

Methodology


ARPA Tri-Service



System-levelModeling

SYSTEM DESIGNSystem Requirements

((4) Executable requirements)

System-level modeling(System Designers)

(1) Performance Modeling

a. ADEPTb. Honeywell PML

(3) FunctionalModeling

a. MAT2DSPb. Ptolemy

(2) DependabilityModeling

a. RESTb. ADEPT

Specifications[Rao94]

(5) bus functional


Design

Methodology


ARPA Tri-Service



Requirements for EffectiveSystem-level Modeling

λ Need a unified environmentµ Need capability for transition from system-level model

to the final implementation in a step-wise mannerλ Need an integrated system-level analysis and

designλ Need to incorporate performance, dependability,

and functional modeling capability at allhierarchies of the design

λ Need to have power and flexibility to modeldigital systems at many different levels ofdescription

µ Support “mixed” simulation at different levels of abstraction, representation, and interpretation with anability for step-wise refinement


Design

Methodology


ARPA Tri-Service



System-level ModelingDefinitions

λ Model: Representation of an entity in some formother than the form in which the entity exists

µ Necessarily lacks some detail of the real systemµ Examples include textual specification, requirements

documents, analytical models, simulation models,physical models

µ Are useful in the design phases when the actual deviceis not available or the necessary experimentation isdestructive, etc.

λ Simulation: The act of animating a model withrespect to some of the parameters of the model

µ An example is movement of tokens representinginformation flow according to the simulation rules of themodel


Design

Methodology


ARPA Tri-Service



System-level ModelingDefinitions (Cont.)

λ Behavioral model: Describes the function and timingof hardware independent of any specificimplementation

µ Can exist at multiple levels of abstraction, depending on thegranularity of the timing and the data types that are used inthe functional description

µ Data flow, procedural and structural constructs may be usedto express behavior

λ Structural model: Represents a system in terms ofthe interconnections of a set of components

µ Components are described structurally or behaviorally, withinterfaces between structural and behavioral-level models

λ Physical model: Specifies the relationship betweenthe component model and the physical packaging ofthe component.


Design

Methodology


ARPA Tri-Service



Abstraction

λ A model is classified as being at a certain level ofabstraction depending on the features of itsbehavior, structure, and timing measures

λ Different levels of abstraction imply thatµ There exists an algorithm for the conversion of a model

at one level of abstraction to another level ofabstraction without loss or gain of information

µ Information describing the system is merely transferredbetween the external algorithm and the systemdescription


Design

Methodology


ARPA Tri-Service



Levels of Abstraction

λ Network levelµ Encompasses performance and interface modelsµ Basic structural model components are processors,

memories, and interconnection elementsµ Behavior is described through the transmission and

receipt of messagesµ Granularity of time is given by response times to

messagesµ Evaluation of response times to stimuli and throughput

of the hardware is possible at this levelλ Algorithmic level

µ Models the functions of a hardware system kernelwithout the functionality or timing of its interface

µ Can be called functional modeling


Design

Methodology


ARPA Tri-Service



Levels of Abstraction (Cont.)

λ Instruction set architecture (ISA) levelµ Functions of an ISA model of a processor are the

instruction set of the processorµ Supports simulated execution of software; if the

compilers are available, can be used to debug thesoftware written for the processor

µ Timing of an ISA model is the time required to performeach instruction of the instruction set of the processor

λ Fully functional levelµ Models all the documented characteristics of the

processorµ Pin behavior of the component is modeled accurately,

both in function and timing


Design

Methodology


ARPA Tri-Service




λ Register-transfer level (RTL)µ Is similar to FFM, but with subtle differencesµ Models undocumented characteristics of the deviceµ Models more of physical characteristics in terms of

internal and interface timing and function than the FFMλ Gate level

µ Constructed structurally with primitive cells thatrepresent Boolean logic functions


Design

Methodology


ARPA Tri-Service




Architectural

Plane of Abstraction

IMPLEMENTATION

DeviceCircuitLogic

FunctionalBlock

Algorithmic

REPRESENTATION

INTERPRETATION

UninterpretedRegion

InterpretedRegion

Physical

Structural

Behavioral

[Schoen92]


Design

Methodology


ARPA Tri-Service



(4) Executable Specifications

λ Executable Specification - specification capableof simulating the required external behavior of asystem

µ Can be treated as a very early prototype of the systemµ Removes the ambiguity associated with written

specificationsµ Bridges the gap between the specifications and designµ Enhances communication among and within customer

and designer groupsµ Enhances high-level of conformance between a

specification model and the performance modelλ Ensures conformance between a specification

and the performance model being developedbased on the specifications


Design

Methodology


ARPA Tri-Service



Executable SpecificationsMIT Lincoln Laboratories

λ RASSP benchmarking of an executablerequirement includes

µ A simulatable model of the systemµ A testbench which sources commands and data, sinks

output data and may perform some checking

SARProcessor

TEST BENCH ?=

= Control

= Data

[Anderson94]

Legend:


Design

Methodology


ARPA Tri-Service



Express VHDL/i-Logix

λ Can graphically create specification modelsλ Generates the equivalent VHDL codeλ Methodology

µ Designer captures the statecharts of the specificationwith the Statecharts Editor

µ Model Execution Tool operates on the statecharts of themodel and animates the behavior of the specification

µ Results in both a screen animation of the specification’sbehavior and a textual trace report of the scenariotested


Design

Methodology


ARPA Tri-Service



(1) Performance ModelingOverview

λ Performance models provide information onsystem timing and do not simulate the functionsof the system being modeled

λ Performance models are typically simulated, notanalyzed

µ Analytical models can rapidly become too complex tofully represent important system features; e.g., resourcecontention

µ Simulation models can accommodate mixed levels ofdesign and various levels of fidelity and accuracy

µ Simulation models suffer from significant startup costs,complexity, and significant execution (CPU) times


Design

Methodology


ARPA Tri-Service



Performance ModelingOverview (Cont.)

λ Performance models support performance andarchitectural tradeoffs (what-if analysis)

µ Facilitate early integration of hardware and software,and documentation of design decisions

µ Aid in identification of bottlenecksµ Serve as a guideline for the model developers, system

architects, and review teams


Design

Methodology


ARPA Tri-Service



Performance ModelingOverview (Cont.)

λ In the early part of the designµ The exact functionality of the components is not knownµ Develop structure, architecture and basic design goals

of the systemλ In the later phases

µ As the functions of the individual components aredeveloped or components are selected from existinglibraries

µ System description can be systematically convertedinto a fully interpreted description for final verification


Design

Methodology


ARPA Tri-Service



Performance Evaluation

λ Typical metricsµ Utilization: Percentage of time the system resources are

busyµ Throughput: The rate at which system can process dataµ Latency (Response Time): Time to process data valuesµ Fault Tolerance: System reliability, safety & availability

λ To allow measurement of these metrics,performance models must have as little detail aspossible


Design

Methodology


ARPA Tri-Service



Uninterpreted Models (Cont.)

λ Used by system designers prior to creatingspecifications for the hardware designers

λ Represents flow of information without regard toinformation itself; deals with presence orabsence of data or control signals

µ Tokens represent presence of information - notparticular values

λ Represents the performance of a system byaggregating the delays associated with tokensflowing through the system


Design

Methodology


ARPA Tri-Service



Uninterpreted Models (Cont.)

Uninterpreted Models

Queuing Models Petri Nets Token-basedSimulation Models

Statistical Data Deterministic/statistical Data (Event-based)

Statistical Data


Design

Methodology


ARPA Tri-Service



Petri Nets

λ Describe the flow of information between“places,” with flow control being defined by“transitions” and “firing rules (mapping)”

λ Simulation rules for the Petri Net describe theconditions for movement of tokens

λ Approach is useful for modeling the actualhardware and software systems

λ Marked Petri Net has a mapping which canassign multiple tokens to each place in the net

λ Colored Petri Net has color fields (mostly integerand Boolean) associated with tokens

µ An uncolored token represents presence of informationonly

µ Useful for adding functionality to the model


Design

Methodology


ARPA Tri-Service



Petri Nets Examples

Process 1 Process 2

Ready to send Ready to receive

Sendmessage

Bufferfull

Bufferfull

Waitfor ack.

Receiveack.

Ack.received Ack.

sent

Sendack.

Messagereceived

Receivemessage

[Murata89],[Dennis70]


Design

Methodology


ARPA Tri-Service



Queuing Models

λ Queuing models represent the system in whichtokens are not serviced immediately, but aremade to wait in a queue for the server to becomefree to service the token

λ Queuing models work well for gaining statisticaldata on very high-level uninterpreted models ofdigital systems

λ At a lower level, the queuing model has difficultyexpressing the deterministic nature of the system


Design

Methodology


ARPA Tri-Service



Queuing Models (Cont.)

Queue Server

Pool of Tokens

Single-server Queuing System

[MacDougall87]


Design

Methodology


ARPA Tri-Service



Token-based SimulationModels

λ Are driven by simulation semantics, and thedynamic behavior of the system is studied

λ Allow arbitrary precision for a given simulationtime

λ Are useful for analyzing huge systems whereanalytical methods are computationallyexpensive (exponential complexity)

λ Examplesµ ADEPTµ RESQµ Honeywell PMLµ ADAS


Design

Methodology


ARPA Tri-Service



ADEPT

ADEPT VIEW

Building Block Model(ADEPT building blocks)

Analytical Model(Colored Petri Nets [CPN])

Simulation Model(VHDL)

Analytical Studies Behavior Performance Dependability

Performance Analysis Behavior Performance Dependability

[Rao94]


Design

Methodology


ARPA Tri-Service



ADEPT (Cont.)

λ Is an integrated design environment that permitslinking of the design phases from initial conceptto the final physical implementation

λ Has an inherent top-down hierarchical designµ A single model from which different representations can

be obtainedµ Building block approach:

θ Has a library of primitive modules; enables the userto define modules and to include them in the library

θ Has VHDL description as well as the underlying CPNrepresentation associated with them

µ Modules may be interconnected to mimic hardware,software, and the interaction between the two

µ Uses CPN theory for development of model reductiontechniques - decreases simulation time


Design

Methodology


ARPA Tri-Service



ADEPT (Cont.)

λ Permits the designers to transcend several levelsof abstraction and interpretation within the sameenvironment using the same language

µ Uninterpreted modeling is supported by a set ofprimitive modeling modules and an underlyingcommunication mechanism

µ Supports simultaneous performance, reliability, andfunctional modeling in a single environment

λ User interface forµ Specifying model; allows user to visually interconnect

modules that constitute the modelµ Allows extraction of performance metrics, graphical

display in the form of bar graphs and waveformsλ Hardware/software codesign techniques can be

developed within ADEPT


Design

Methodology


ARPA Tri-Service



Honeywell PerformanceModeling Library (PML)

λ Targeted towards high-level description,specification, and performance analysis ofcomputing systems at a system level

λ Serves as a simulatable specification, aids theidentification of bottlenecks, and supportsperformance validation

λ Can be used for capturing and documentingarchitectural-level designs, and can be used as atestbed for architectural performance analysisstudies

λ Provides VHDL performance model within theRASSP design environment


Design

Methodology


ARPA Tri-Service



Honeywell PML

Performance

HybridBehavioral

Requirements

Design

Test/Integ

Build

Generic Library

Arch. Perf.Model

System Requirements

Executable

Hardware requir.Decomposition Anal.

VHDLHardware

Perf. Model

VHDL Behavioral- level Model

VHDL Gate- level Model

Prototype Hardware

Software Requir.Decomposition Anal.

Software Perf. Model

Software PDLPrototype

Code

MODELING

Honeywell


Design

Methodology


ARPA Tri-Service



Honeywell PMLFeatures

λ Generic building blockµ Can be assembled and configured rapidly to many

degrees of fidelity with minimal effortµ Modules are interconnected with structural VHDLµ Types available

θ Configurable input/output devicesθ Memoriesθ Communication elementsθ Processor element

λ Appropriate to apply at architectural levelµ Actual device under study (such as a signal processor)

and its environment (such as sensors and actuators)


Design

Methodology


ARPA Tri-Service



Honeywell PML

λ Standard output routines tabulate and graphperformance statistics such as latency,utilization, and throughput

λ Interoperability guidelines ensure that modelsfrom multiple sources will integrate smoothly

λ Hybrid models support smooth integrationbetween performance and functional models

λ Capable of representing systems consisting ofASICs, boards, subsystem cabinets, and sensornetworks

λ Effect of software on the architecture can becharacterized and modeled


Design

Methodology


ARPA Tri-Service



Interpreted Models

λ Includes behavioral models and functional modelsλ Contain functions and data values to be transformed

according to these functionsλ More diverse and difficult to classify

µ Behavioral or language-based models: Programming designlanguage (PDL) constructs allow the development ofsimulation models

θ VHDL (IEEE and DoD standard)θ Do not specifically address hardware timing considerations

µ Structural or primitive (macro-) based models: (Gate-levelmodels): Allow the system to be specified in terms ofpredefined primitive elements

µ Physical models: (SPICE): Describe the system in terms of thefundamental differential equations that govern the circuit anddevice operation


Design

Methodology


ARPA Tri-Service



Hybrid Models

λ Contain uninterpreted and interpreted elementsattributes

µ Use HDLs and their simulatorsµ Adding uninterpreted modeling to HDLs provides a

single design environmentµ Communicating between different regions takes place

through interfaces which convert tokens to values andvalues to tokens

λ Delay statistics of the interpreted models can beback-annotated with the statistics obtained fromthe hybrid model, giving an “improved”uninterpreted model


Design

Methodology


ARPA Tri-Service



Hybrid Models

λ Uninterpreted-to-interpreted conversionµ Requires that the input values be supplied to the

interpreted modelµ Tokens can be tagged with necessary values - values

are read from tokens and applied to interpreted modelµ Values can be generated from

θ List of known valuesθ Values based on probability distributions

λ Interpreted-to-uninterpreted conversionµ Requires quantization of output data into tokensµ Effective loss of informationµ Quantization of information into tokens can occur on an

event withθ No change in value, on a particular value, on a

change in value


Design

Methodology


ARPA Tri-Service



ADEPTHybrid Modeling

The Interpretation Interface

U4

I5U1

U2 U3

U/I

A

U5TokenInterpreted Values

Eval

uato

r[ADEPT UM94]


Design

Methodology


ARPA Tri-Service



Object-oriented AnalysisShlaer-Mellor Model

λ Highest-level partitioning construct - domainµ Is a set of conceptual entities, or objects, that can exist

independently of the objects in other domainsµ May be partitioned into one or more subsystems, each

consisting of a set of related objectsµ Hardware/software partitioning is done using domains

λ Within a subsystem, objects are represented in anobject information model

µ Attributes of an object are used to define its characteristicsµ A connection between two objects in the information model

represents a relationship that holds between themµ Relationship includes one-to-one, one-to-many, and many-

to-manyµ Object-information model also supports inheritance

relationships


Design

Methodology


ARPA Tri-Service



Object-oriented Analysis

λ A state model describes the behavior of objectinstances throughout their lifecycle

µ A state model consists of a set of states and eventsµ An object instance can only be in one state at any given

point in time; an event causes a transition from onestate to another

µ Different object instances execute concurrently and canbe in different states simultaneously


Design

Methodology


ARPA Tri-Service



Object-oriented Analysis(Cont.)

λ An activity, or action, is executed when an objectarrives at a state

µ State models synchronize and communicate with eachother using events

µ During execution of an action, an object instance maygenerate an event destined for itself or another objectinstance

µ A definition of the processing that takes place as part ofan action is termed process model


Design

Methodology


ARPA Tri-Service



Advantages of OO-VHDL(Cont.)

λ Benefit: No Compatibility Problems between Modelsλ Enables: Interoperability among object components

Any object can send/receive from any other object.Object communication protocol implicitly defined.

OO-VHDLMessaging

Signals andGlue Logic

Object X Object Y Component X Component Y

OO-VHDL Object ComponentsOO-VHDL Object Components VHDL ComponentsVHDL Components

Vista Technologies, Inc.


Design

Methodology


ARPA Tri-Service



(2) Dependability Outline

λ Dependability Modelingµ Errors and faultsµ Definitionsµ Needµ Additional metricsµ Evaluation metricsµ Analytical techniquesµ Simulation-based techniques


Design

Methodology


ARPA Tri-Service



λ Fault: Is a physical defect, imperfection, or flaw that occurswithin some hardware or software component

λ Error: Is a manifestation of a fault - deviation from accuracyor correctness

λ Failure: Is the non-performance of some action that is dueor expected - Also the performance of some function in asubnormal quantity or quality

λ Latent fault: Is one that is present in a system but has notyet produced an error

µ Fault Latency: Time between the occurrence of a fault andappearance of an error due to that fault

Errors and Faults

λ FFAULT ERROR FAILURE

Physical Universe Informational Universe External Universe


Design

Methodology


ARPA Tri-Service



Errors and Faults (Cont.)

Cause-Effect Relationships

λ Error Latency: Is the length of time between theoccurrence of an error and the appearance of theresulting failure

SpecificationMistakes

Implementation Mistakes

External Disturbances

ComponentDefects

Software Faults

Hardware Faults

Errors System Failures

[Johnson89]


Design

Methodology


ARPA Tri-Service



Dependability ModelingDefinitions (Cont.)

SafetyThe probability that a system will either perform itsfunctions correctly (reliability) or will discontinue itsfunctions in a manner that does not disrupt theoperation of other systems or compromise the safety ofany components associated with the systemProvides a measure of fail-safe capability of a system

PerformabilityThe probability that the system performance will be at,or above, some level L at the instant of time tUsed as a measure of performance of a system whenthere are failures in the systemGraceful degradation: Is the ability of a system toautomatically decrease its level of performance tocompensate for hardware failures and software errors


Design

Methodology


ARPA Tri-Service




MaintainabilityThe probability that a failed system will be restored toan operational state within a specified period of time tA measure of the ease with which a system can berepaired once it has failed

TestabilityThe ability to test for certain attributes in a systemDescribes the ease with which certain tests can beperformed


Design

Methodology


ARPA Tri-Service




DependabilityIs the quality of service that a particular systemprovides

Includes reliability, availability, safety, maintainability,performability, and testability

Currently, reliability is the main concern, as it is themost tractable and important concern independability modeling


Design

Methodology


ARPA Tri-Service



Need for DependabilityModeling

λ Because of increasing complexity of digitalsystems, systems have become less reliable

µ Long-life applications: Maintainability, safety, andperformability become important

µ Critical-computation applications: Need high reliabilityµ Maintenance postponement applications: Maintenance

is costly, need performabilityµ High-availability applications: Banking applications

λ Recently, digital systems have become cheap; socan afford to add redundant components toimprove reliability and, to some extent, otheraspects of dependability


Design

Methodology


ARPA Tri-Service



λ Failure rateµ The expected number of failures of a type of device or

system in a given period of time

λ Mean time to failure (MTTF)µ Is the expected time that a system will operate before

the first failure occurs

λ Mission time MT[r]: Is the time at which thereliability of a system falls below a level r

µ Systems can be compared by the ratio of mission times

Additional Metrics

z(t) dR(t)dt

1R(t)

= −

MTTF t R t dtii

N =

N ==∑

∞∫ ( )


Design

Methodology


ARPA Tri-Service



λ Mean time to repair (MTTR)µ Average time required to repair a system

µ MTTR is given by repair rate µµµµ, which is the averagenumber of repairs that occur per time period, MTTR=1/µµµµ

λ Mean time between failures, MTBF = MTTF+MTTRλ Fault coverage

µ Measure of a system’s ability to perform fault detection,fault containment, and/or fault recovery

µ Ex: Fault detection coverage factor

Additional Metrics (Cont.)

MTTRN

tii

N=

=∑

number of faults that can be detectedtotal number of faults=


Design

Methodology


ARPA Tri-Service



Analytical Techniques

DependabilityModeling

Simulation-basedTechniques

AnalyticalTechniques

MarkovModels

CombinatorialModels


Design

Methodology


ARPA Tri-Service



Analytical Techniques (Cont.)

λ Advantagesµ For accurate modeling assumptions, the solution is

accurate and deterministicµ Can be solved in continuous time with high accuracy

λ Disadvantagesµ Based on models of the components, so details of the

system behavior might be lost in the modelingassumptions

µ State-based models are difficult to solveθ Exponential time and space complexity


Design

Methodology


ARPA Tri-Service



Analytical Techniques (Cont.)

λ Combinatorial modelsµ Are difficult to construct and the reliability expressions

are often very complexµ Difficult to incorporate fault coverageµ Process of repair is difficult to incorporate

λ Markov modelsµ Rely on two mechanisms to describe system:

θ System state: Represents all that must be known todescribe the system at any given instant of time. Itrepresents a distinct combination of faulty and fault-free modules

θ State transitions: Described as probabilities thattransitions will occur between adjacents states

µ Set of simultaneous differential equations providesaccurate solutions for stated transition probabilities


Design

Methodology


ARPA Tri-Service



λ Two types of connectionsµ Series: the system contains no redundancy

µ Parallel: only one of the elements is required for thesystem to function

Combinatorial Models

R t R ts e r i e s ii

n( ) ( )= ∏

=

− = − − −R t R t R t R tparallel n( ) [ ( )][ ( )]...[ ( )]

Cn

C

C

C C Cn


Design

Methodology


ARPA Tri-Service



Semi-Markov UnreliabilityRange Evaluator (SURE)

λ Calculates the upper and lower bounds on theprobability of failed state of a Markov model

µ Requires solution of a set of coupled differentialequations

λ Computes probabilities using algebraic formulas,large state spaces can be accommodated

λ Based onµ White’s method: The means and variances of the

recovery times are sufficient to obtain tight bounds onthe probability of system failures

θ Useful in design studies in which properties of fastdistributions are assumed

µ Lee’s theorem:θ Useful in analysis where experimental data is

available


Design

Methodology


ARPA Tri-Service



λ Advantagesµ Flexible, no restrictions caused by computational

complexityµ Detailed, no modeling assumptions madeµ Arbitrary precision for a given simulation time

λ Disadvantagesµ Low failure rates and high repair rates require large

number of simulationsµ Reducing the size of the model, by taking into account

only relevant components (importance sampling)

Simulation-based Techniques


Design

Methodology


ARPA Tri-Service



Reliability Estimation SystemTestbed (REST)

λ Software system designed by NASA to supportµ The hardware reliability analysis of complex fault-

tolerant computer systemsµ Simulates failure modes and effect analysis (SFMEA)

and automatically generates and analyzes a semi-Markov model of the system of interest

µ Calculates upper and lower bounds on the probability ofencountering a failure state and a summary ofconditions under which those failures occur

λ Main componentsµ REST modeling language, RMLµ Translatorsµ An X Window front window


Design

Methodology


ARPA Tri-Service



REST

λ REST modeling language (RML)µ Uses “modules” to describe simple components and

complex systems of such componentsµ Types of module variables

θ State variablesθ Rate variablesθ Relation variablesθ Event declarations

λ System definition starts by creating a list of allthe module types to be found in the system

λ Model analysis portionµ Takes the system description and repeatedly

transforms the system state in accordance with rulesgiven with module type definition


Design

Methodology


ARPA Tri-Service



REST (Cont.)

λ REST translatorµ Maps all the state variables implicit in the declaration of

module variables onto a global state vectorµ Requires local variables to be handled by the user

explicitlyλ REST run-time system

µ Responsible for all analysis, and sequencing of routinesdeclared in the RML modules


Design

Methodology


ARPA Tri-Service



(3) Functional Modeling

λ Describes the function of the hardware/softwaresystem kernel, but not the functionality or timingof the interface.

µ Uses the information about the structure of thecomponent to be modeled

λ Examplesµ MAT2DSPµ Ptolemy


Design

Methodology


ARPA Tri-Service



Functional Modeling withMATLAB

λ MATLAB is a high-level signal processingsoftware package built from a set of primitivefunctions

µ Vector-vector and vector-matrix multiplies, FFT,convolution, filtering

µ Operating on data vectors or arraysλ The algorithm chosen to solve a particular

problem has a tremendous impact on thecomplexity and cost of the final implementation

λ MATLAB attempts to bridge the gap betweenalgorithm development and its hardware/softwareimplementation

λ Multiple algorithmic solutions for any problemhave different cost/performance trade-offs


Design

Methodology


ARPA Tri-Service



MAT2DSP

λ Developed by University of California, Davisλ Estimates the implementation requirements of

algorithms specified in the form of a MATLABprogram

λ Future versions will take into account more detailedinformation related to dataflow, program overhead,and data transfer times

λ Target programµ MATLAB program that implements a given signal/image

processing algorithmµ MAT2DSP program operates on this program and produces

one of several user-selected reports which containsinformation about the computational requirements of thealgorithm and an estimate of its runtime on a user-specifiedprocessor or a mix of processors


Design

Methodology


ARPA Tri-Service



λ Different types of reports of varying levels ofcomplexity can be generated based on the datacontained in the primitive list and the database

MAT2DSP

TranslatorModified Program

ExecutePrimitive List

Target Program

Database

Report Generator Program

MATLAB Program

MATLAB Program

Number and types of computations performed

by the target programRun-time of the target

program on a user-specified processing hardware


Design

Methodology


ARPA Tri-Service



Ptolemy

λ System-level design frameworkµ Covers higher levels of system specifications as well as

lower level of system descriptionθ Implements heterogeneous embedded systemsθ Allows mixing models of computation and

implementation languagesµ Provides graphical specification of system parameters

and mathematical models of systemsµ Supports hierarchy using object-oriented principles of

polymorphism and information hiding in C++µ Provides capability for interaction between different

domains


Design

Methodology


ARPA Tri-Service



Ptolemy (Cont.)

λ Special Featuresµ Graphical interface (pigi, Ptolemy interactive graphical

interface), based on vem, a graphical editorθ Animation and visualization

µ Multidimensional signal processing dataflow modelsµ higher order functionsµ Silage and VHDL code generationµ Interfaces to other design tools; e.g., MATLAB and

Hyperλ Applications

µ Signal processing, telecommunications, wirelesscommunications, network design

µ Parallel processing, real-time systems,hardware/software codesign


Design

Methodology


ARPA Tri-Service



PtolemyCapabilities

λ Design of signal processing and communicationsystems

µ Specifying, designing, and simulating algorithms tosynthesize hardware and software

µ Providing techniques for dataflow modeling ofalgorithms

µ Managing regularity in dataflow graphs using higherorder functions

µ Synthesizing embedded software from dataflow modelsµ Scheduling dataflow graphs on uniprocessors and

multiprocessors efficientlyµ Supporting hardware/software partitioning of dataflow

graphsλ Parallelizing algorithmsλ Prototyping real-time systems


Design

Methodology


ARPA Tri-Service



(5) Bus Functional Models

λ Interface models that describe the functionalityand timing of the interface (e.g. of processors ormemories) to a bus

λ Descriptions are at network level of abstractionλ Only enough detail is included to model external

behavior of the device - internal state is notmodeled

µ E.g., processor model will perform bus cycles formemory read/write, but will not execute actual code

λ Internal control language is sometimes used toallow user to program different bus cycles

λ Obtained byµ Commercial suppliers (Logic Modeling Group, Synopsys, Inc.)

µ Bus functional model generators (OmniView)


Design

Methodology


ARPA Tri-Service



Bus Functional ModelsExample

i860Bus Functional

Model

Model Specific “Programming Language”

cache_read(inst,8,PIPE,80000h);nc_read(data,8,PIPE,var1,81000h);nopnc_read(data,8,PIPE,var2,81008h);

CLKRESET

INT

32

20

64

ADDR

CNTL

DATA

BRDY

SimulatedBusCycles


Design

Methodology


ARPA Tri-Service



Bus Functional ModelGeneration - ALCHEMIST

User Input GeneratedOutput

ALCHEMIST

Cycles

States

Timing Diagrams

Timing Specifications

Action Tables

GraphicalModel-

CaptureSystem

AnalysisEngine

Model Generator

VHDL Models

Verilog Models

PostscriptDocumentation

ASCIIDocumentation


Design

Methodology


ARPA Tri-Service



Summary

λ The general forms of system level modeling wereintroduced

µ Performance Modelingµ Dependability Modelingµ Functional Modelingµ Executable Requirementsµ Bus Functional Models

λ The goals of each type of modeling and where itfits into the design process was discussed

λ Examples tools for each type of modeling werepresented

Version D 0.2 Fall 2000 -...

Documents

Transcript of Version D 0.2 Fall 2000 -...