definition of transactional abstraction levels needed for...

Definition of transactional abstraction levelsneeded for a precise architecture evaluation in

the Systems-on-Chip’s Design Flow

Florence Maraninchi, Jérôme Cornetand Laurent Maillet-Contoz

Verimag - CNRS - STMicroelectronics

Jérôme Cornet Synchron 2005 1

Outline

1 Context

2 Timing evaluation at high level of abstraction

3 Problem

4 Research


Context

Outline

1 ContextSystems on ChipTypical design flowDesign problemsTransactional Level ModelingResearch topics


3 Problem

4 Research


Context Systems on Chip

What are Systems on Chip ? (SoC)

Chips integrating all necessary electronic circuits for a"system"

Applications : Cell phones, DVD, Set-top boxes, MP3players, Automotive...

Key characteristicsHigh level of integrationSoftware and hardware partsApplication Specific Integrated Circuits

CPU RAM DSP

DMA I/O

Interconnect


Context Typical design flow

Typical design flow

Various abstraction levels

Main entry point : Register Transfer Level (RTL)

Tools to reach automatically lower levels

RTL

Gate level

Layout

Synthesis, Optimization

Place & Route

Netlist

VHDL, Verilog

MasksBitstream


Context Typical design flow

Register Transfer Level

ContentComponents connected by wiresLogical values (0, 1, ...) carried by the wiresSynchronous circuits description

Time and bit accurate

Available at the end of the design cycle


Context Design problems

Common problems

Increasingly complex circuits: "design gap"

Pressure on Time to market

Skyrocketing costs

Very expensive to fix hardware bugs (masks cost)

Bugged chips already delivered?

Two big classes of design problems:

Physical problems

System-level problems


Context Design problems

System-level problems

Slow RTL simulationex: encoding/decoding one MPEG-4 frame takes 1 hour

to simulate

Late availability of RTL

Late writing of software parts

Late discovery of integration bugs


Context Transactional Level Modeling

Transactional Level Modeling (TLM)

RTL

Gate level

Layout

TLM

New level of abstraction

Written before RTL

Fast simulation speed

previous MPEG-4 ex: 3 seconds to simulate (× 1200)

Lightweight modeling effort



Transactional Level Modeling (TLM)

Allows:

Early embedded software validation

Virtual prototyping

Written in SystemC

Standardized by Open SystemC Initiative (OSCI)



TLM: idea

RTL

TLM

Bus communications abstraction



TLM: description

Contract between embedded software and hardware

ComponentsAccurate modeling of register banks, systemsynchronizations

CommunicationsTransactions

Logicial operations on buses: read, write, ...

Master or Slave ports with assigned addresses

Interrupt signals

CharacteristicsClocklessBit accurate



TLM : example

Generator 1

1 2

1 2

Shared memory Generator 2

Timer

Bus 1

Bus 2


Context Research topics

Research topics in the team

Formal verification of transactional-level platforms

Automatic generation of tests

Comparison between RTL and TLM

Timing evaluation at transactional level


Timing evaluation at high level of abstraction

Outline

1 Context

2 Timing evaluation at high level of abstractionCoarse-grain approachesPV/PVT

3 Problem

4 Research


Timing evaluation at high level of abstraction Coarse-grain approaches

Coarse-grain approaches (1/2)

Rough abstraction of architecture and timings"Labels" on componentsProblem: composition law between labels?

References: [RSL04], [CKT+03], [JRE04], [TCN00], [TC94]

A B C

D E






A B C

D E

t1 t2 t4

t3t2






A B C

D E

t1 t2 t4

t3t2?Composition

Law




Actually dataflow analysis oriented

Suited for using theory of performance evaluationQueuing NetworksLayered Queuing NetworksStochastic Automata Networks...

Component structure not always appropriate forperformance analysis


Timing evaluation at high level of abstraction PV/PVT

PV/PVT (STMicroelectronics)

Two abstraction levels inside TLMProgrammer’s ViewProgrammer’s View with Time

RTL

Gate level

Layout

TLM PVT

TLM PV



PV/PVT: description

PV levelDesigned for:

Embedded software validationPlatform integration

Time has no meaning at this level

PVT levelDesigned for:

Architecture evaluationTiming-sensitive parts of embedded software validation

Contains: PV + microarchitecture model



PV/PVT : microarchitecture model

Model’s ingredients1 Granularity

2 Microarchitecture features (fifos, pipeline...)3 Timings

A

1 2

Bus



PV/PVT : microarchitecture model

Model’s ingredients1 Granularity

2 Microarchitecture features (fifos, pipeline...)3 Timings

Bus

OFIF

ControlOFIF

Pipeline



PV/PVT : constraints (1/2)

RTL

TLM PVT

TLM PV




RTL

TLM PVT

TLM PV

Samefunctionalbehavior




RTL

TLM PVT

TLM PV






RTL

TLM PVT

TLM PV



Sametimedbehavior




RTL

RTLTransactions

PVT

PV

Read ReadWrite Read Write WriteRead Write

Read Write

Read ReadWrite Read Write WriteRead Write

Traces example:

PV reuse in PVT


Problem

Outline

1 Context


3 ProblemDescriptionExample

4 Research


Problem Description

Problem description (1/2)

ProblemGiven:

PV referenceMicroarchitecture, temporal laws

Build: PVTWith same functionality as PVWith same temporal behavior as RTL microarchitecture

No automatic build of PVT for now


Problem Description

Problem description (2/2)

Approach: for each component,Build PVT = PV ⊕ T

PV : unmodified PV model of the component

T : standalone microarchitecture model

⊕ : "glue", synchronization between PV and T ,some kind of weaving?

Hopes:Maintain PV’s functionality by construction

Consistency of behavior between PV and T

Guarantee correct behavior of composed components


Problem Example

Example (PV)

Generator 1PV

1 2

1 2

Shared memoryPV

Generator 2PV

TimerPV

Bus 1

Bus 2


Problem Example

Example (PVT)

Generator 1PVT

1 2

1 2

Shared memoryPVT

Generator 2PVT

TimerPVT

Bus 1 - PV fiber

Bus 2 - PV fiber

Bus 1 - PVT fiber

Bus 2 - PVT fiber


Problem Example

PVT module’s structure

Generator 1PVT


Problem Example


Generator 1PV


Problem Example


Generator 1PV

Generator 1T


Research

Outline

1 Context


3 Problem

4 ResearchSummaryModel


Research Summary

Formalizing the approach

Building an abstract model that captures PV , ⊕, T , PVT

Proving properties about:

Functional consistency between PV and PVT

Logical consistency betwen PV and T

Separation of elements added to PV

⊕ and T

Basic building blocks within T

Automation?


Research Model

Model


Conclusion

PV/PVT: a good example ofSeparation of concerns: functional/timed

Fine-grain architecture modeling

ResearchGuarantee properties about the process "by construction"

Rules about writting PV and T

Provide some kind of automation in the long term

To do (also)Complex PV/PVT behaviors

How to model components with functional time?(timer, uart, etc.)


Research Model

Generalities

GeneratorPV

MemoryPV

Bus

Component architecture description

Behavior’s description by automata inside components

Two levels of parallelism:Between componentsInside components ("threads")


Research Model

Generalities

! !

Component architecture description

Behavior’s description by automata inside components

Two levels of parallelism:Between componentsInside components ("threads")


Research Model

Communications between components

Master (initiator) actions

!write(port, @, data)

!read(port, @) returns a data

!sync(data) (for communications by interruptions)

Blocked until execution of return action

Slave (target) actions

?write(port, @, data)

?read(port, @)

?sync(data) (for communications by interruptions)

return


Research Model

Example

port1

a := 0x1000

[a < 0x2000]!write(port1, a, 42)

d := !read(port1, a)a++

Component with master port: Generator PV


Research Model

Example

port

?read(port, @)

return

?write(port, @, data)

return

Component with slave port: Memory PV


Research Model

Model elements for PVT

Previous elements

Distinguishing different transactions size with differentactions for convenience

littlewrite(port, @, data) (both ? and !)

littleread(port, @) (both ? and !)

Action for time elapse: wait(time)


Research Model

Example

GeneratorPVT

Generator PVT


Research Model

Example

GeneratorT

GeneratorPV

Generator PVT


Research Model

Example (Generator T)

port2 port3

GeneratorT

port1

Generator T


Research Model


port2 port3

port1

?read(port1, @)

!read(port2, @)i :=0

[i < 10]!littleread(port3, @)

i++

[i ! 10]return

?write(port1, @, data)

!write(port2, @, data)i := 0

[i < 10]!littlewrite(port3, @, data)

i++

[i ! 10]return

Generator T


Research Model


port2 port3

port1

?read(port1, @)

!read(port2, @)i :=0


i++

[i ! 10]return




i++

[i ! 10]return


Research Model


port2 port3

port1

?read(port1, @)

!read(port2, @)i := 0


i++

[i ! 10]return




i++

[i ! 10]return

+ synchro


Research Model

Example

MemoryT

MemoryPV

Memory PVT


Research Model

Example (Memory T)

port2 port3

port1

?read(port2, @)

!read(port1, @)

return


!write(port1, @, data)

return

?littleread(port3, @)

wait(5 ns)

return

?littlewrite(port3, @, data)

wait(8 ns)

return


Research Model

Communications inside components

port1 port2


[@ = 0x04 ! data = 1]a := 0x1000

[else]return

"ereturn

!ea := 0x1000

[a " 0x2000]return

[a < 0x2000]d := !read(port2, a)

!write(port2, a, d)a++

Shared variables

Event actions↑e (immediate notification on e)↓e (wait for e)


Research Model

Bibliography I

Samarjit Chakraborty, Simon Künzli, Lothar Thiele, AndreasHerkersdorf, and Patricia Sagmeister.Performance evaluation of network processor architectures:combining simulation with analytical estimation.Computer Networks, 41(5):641–665, April 2003.

Marek Jersak, Kai Richter, and Rolf Ernst.Performance analysis for complex embedded applications.International Journal of Embedded Systems, Special Issue onCodesign for SoC, 2004.

Gopal Raghavan, Ari Salomaki, and Raimondas Lencevicius.Model based estimation and verification of mobile deviceperformance.In Proceedings of the fourth ACM international conference onEmbedded software, pages 34–43. ACM Press, 2004.


Research Model

Bibliography II

K. Tindell and J. Clark.

Holistic schedulability analysis for distributed hard real-timesystems.

Microprocessing and Microprogramming - Euromicro Journal(Special Issue on Parallel Embedded Real-Time Systems),40:117–134, 1994.

Lothar Thiele, Smarjit Chakraborty, and Martin Naedele.

Real-Time Calculus for Scheduling Hard Real-Time Systems.

In International Symposium on Circuits and Systems ISCAS,Geneva, Switzerland, volume 4, pages 101–104, March 2000.


definition of transactional abstraction levels needed for...

Documents