# TKT-1212 Digitaalijärjestelmien · PDF fileTKT-1212 Digitaalijärjestelmien...

date post

18-Aug-2018Category

## Documents

view

230download

0

Embed Size (px)

### Transcript of TKT-1212 Digitaalijärjestelmien · PDF fileTKT-1212 Digitaalijärjestelmien...

A. Kulmala, E. Salminen, TUT, Spring 2009

Lecture 8 Simulation engines

Ari Kulmala, Erno Salminen 2009

TKT-1212 Digitaalijrjestelmien toteutus

A. Kulmala, E. Salminen, TUT, Spring 2009

ContentsModeling dimensions

1. Temporal2. Data abstraction3. Functional4. Structural

Basic simulator typesEvent-driven simulation enginesCycle-aseb simulation engines

Waveform viewers and summary

A. Kulmala, E. Salminen, TUT, Spring 2009

IntroductionVerification => Functional correctnessTesting => Manufacturing correctnessDesign Under Verification (DUV)Much of design time is spend on developing the verification environment and debugging HDLSimulation based verification is the most common

The heart is the simulation engineModels the behavior of the designSupports high-level verification languages (e.g. Vera), code coverage tools etc.

3

A. Kulmala, E. Salminen, TUT, Spring 2009

Acknowledgements

4

This presentation is based on the book Comprehensive Functional Verification: The Complete Industry Cycle by Bruce Wile, John Goss, and Wolfgang Roesner

Some examples obtained from Mentor Modelsim manual

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling dimensions

Model is a simplification of reality and every system is best approached through a small set of nearly independent models

Booch & Rumbaugh

5

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling dimensions#1: Temporal1. Temporal dimension -Behavior over time, i.e. when the

state changesI/Os represent the state of the DUV

a) Continuous time (Analog)Fairly close to physical properties of electrical circuit

b) Discrete timeDigital, electrical properties abstracted, delta delay, events occur seemingly simultaneouslyClock cycleNo wiring or gate delays

c) Event-based (instruction-level, transaction-level)Waits for certain events, time between events varies

6

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling dimensions #2: Data2. Data abstraction - Signal values

a) Continuous range (analog)E.g. voltage measurement, arbitrarily accurate real numbers

b) Discrete valuesBits, strings, integers, states

E.g. std_logic:1, 0, u, x, z, H, L

Abstract values, e.g. user defined enumeration statesMain, read_io, write_io

Structs combine several abstract values

7

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling dimensions #3: Function3. Functional Dimension

May just be Continuous mathematical functions (e.g. Spice simulator)Select level of abstraction

Transistors -> switches -> Boolean Logic -> Algorithms -> Abstract mathematical formula

E.g.:a) Boolean (half) adder:

z0 = x0 xor y0 C1 = x0 and y0

b) Algorithm+ (automatic implementation or user defined)

c) Abstract formulaThe whole functionality is specified with abstract implementation-independent notationsx=(2+y)^z mod a

8

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling dimensions #4: Structure4. Structural Dimension

a) Flat (single black box)No structurality, just implementation, eg. FFT with abstarct mathematical formula

b) HierarchicalImplementation is structural

Many subblocks

Many components that have subblocks

E.g. FFT has subblocks for add and multiply

FFT

FFT+

*

+

*

Input Output

Input Output

9

A. Kulmala, E. Salminen, TUT, Spring 2009

VHDL support for modeling dimensionsTemporal

Continuous Gate Delay Clock CycleIntruction

CycleEvents

Data

Continuous Multivalue Bit Bit Abstract Value Struct

Functional

Continuous Switch Level Boolean Logic Algorithmic Abstract Mathematical

Structural

Single black box

Functional blocks

Detailed component hierarchy

10Verilogs support

A. Kulmala, E. Salminen, TUT, Spring 2009

Modeling compromise: Speed vs. Accuracy

RTLStyle

Gate-levelstyle

Gate-level with detailed

delays

Simulation runtime and memory requirements

Model details and accuracy11

More speed -> more abstract models -> more test cases within same time, but less accuracy.Designers should start with high-level models

Basic verification, something like this could workGradually refine the models if needed

A. Kulmala, E. Salminen, TUT, Spring 2009

Simulation engines

A. Kulmala, E. Salminen, TUT, Spring 2009

Simulation engine typesEvaluate HDL model over time and present its state

Standardization: The HDL language reference manual (LRM) defines the behavior of the simulation engine.

1. Evaluate signals and blocks only at model times for which eventsare scheduled

Event-driven simulation enginesMajority of simulators are in this category, e.g. ModelSimEvaluate only the active parts

2. Evaluate the model at every point of time along the finest granularity known to the simulation engine

Cycle-based simulation enginesSimpler simulator and hence fasterCommonly evaluate the whole model regardless of activity

13

A. Kulmala, E. Salminen, TUT, Spring 2009

Simulation engine

HDL Model

Basic HDL simulator block diagramInteractive user control GUI

HDL model of DUV

HDL Testbench

stimuluscheck

stimuluscheck

Trace Files

Coverage Files

Interactive waveform viewer GUI

Testbench program

Interactive testbench

debug GUIstimulus

check

14

Interactive coverage analysis GUI

A. Kulmala, E. Salminen, TUT, Spring 2009

Event-Driven Simulation Engines

15

A. Kulmala, E. Salminen, TUT, Spring 2009

Event-driven simulationMost popular approach,

Used also in other areas since it is very general approachChannels or signals transfer data between blocksBlocks process data at its inputs which may initiate a new transfer.

Engine acticates only those blocks whose inputs changeAlgorithm to evaluate time:

Evaluate signals and blocks only at model times for which events are scheduledThe model objects need to notify the simulation engine about future changes scheduling engine may skip unused time intervalsSimulator keeps track of current time and when events are scheduled events

16

A. Kulmala, E. Salminen, TUT, Spring 2009

Event-driven simulation (2)Scheduling is done in internal time intervals if no delay is specified

Zero-delay scheduling (delta delay), most usual in RTLEach scheduling step evaluation creates a resulting update to the next occuring stepParallel updates are handled sequentially by the engine, effectively randomly

Signal changes propagate through the model as the scheduling progressesFeedback loops may cause endless oscillation

User or the engine must take action to interrupt uncontrolled oscillationUsually bad HDL design, e.g. combinatorial loop

17

A. Kulmala, E. Salminen, TUT, Spring 2009

Simulator exampleSimulating a top level having two blocks, which contain 3 sub-blocks, b1, b2, c1.

inputs model outputs

i1

i2

a1

a2

s1

s2

s3

s4

s5 s6

a3

a4

s7

s8

s9a5

a6

a7 o1

o2

18

Signal directions imply partial order for the evalutation.

A. Kulmala, E. Salminen, TUT, Spring 2009

Sim. example: evaluation over timeA change occurs in i1Simulator starts to evaluate the model over time by steps (delta delay)

B1

B2

C1

inputs model outputs

i1

i2

a1

a2

s1

s2

s3

s4

s5 s6

a3

a4

s7

s8

s9a5

a6

a7 o1

o2

i1 a1 s1 B1

s3

a3 s7 C1

B2 s6 a6

s4

o2After reaching o2, simulator goes back to one of the uncompleted branches (a3 or s4). Their mutual order is not specified.

Block B2 might be evaluated twice (due to S4 and S5)

Signal update

Block evaluation

Simulator engines scheduling steps19

A. Kulmala, E. Salminen, TUT, Spring 2009

Another example

20

s9s10

s11

s12 s13

s7

s8

1.

2.

3.

4.

5.

A. Kulmala, E. Salminen, TUT, Spring 2009

Another example: Update sequence

21

...

...

A. Kulmala, E. Salminen, TUT, Spring 2009

Example of how network view is constructed from VHDL

22

user-defined signal name

simulators internal signal

A. Kulmala, E. Salminen, TUT, Spring 2009

Signal assignment1. concurrent - in an architectural body

Signal activities control not top-down flow - their execution order

2. sequential - inside a process, top-down orderingThe value on the right side will be scheduled for the left side

Value is placed on the driver of the left-hand side signalMultiple concurrent assignments produce multiple drivers

That is legal if the signal type defines resolution function which resolves a single value from multiple drivers

Sequential body (i.e. process) may have multiple assignment but they produce only a single driver

Note that this includes both sequential (synchronous) and combinatorial (asynchronous) processesThe last assignment in HDL is kept

Last assigned value (in time) is kept unless otherwise stated -> may require state-holding logic in synthesis (DFF or latch)

A. Kulmala, E. Salminen, TUT, Spring 2009

Events and transactionsSignal assignment may have an associated delay

An eve