Modelling of Systems on Chip - McGill...

1

Modelling of Systems on Chip

Part of Tutorial A:Automatically Realising Embedded SystemsFrom High-Level Functional Models

Wido Kruijtzer, Victor ReyesNXP SemiconductorsMarch 10, 2008

2

DATE 2008 Tutorial A - Wido Kruijtzer / Victor Reyes March 10,20082

Outline

NXP Products / challenges

Abstraction Levels

Functional Modeling

Architecture Modeling

Summary

2

3


NXP Semiconductors – Reborn and Renewed

Spin-out of Royal Philips Electronics’Semiconductor Division

#2 in Europe, Top-10 global supplier

Sales of € 4.6 billion in 2007

37,000 employees / 7,500 engineers

Investing € 950 million in R&D annually

25,000+ patents

More than 26 R&D centers in 12 countries

Headquarters: Eindhoven, The Netherlands

Key focus areas: – Mobile & Personal, Home,

Automotive & Identification, Multimarket

4


Feature explosion in consumer productsImaging Main display

Aux displayCamera3D display3D rendering

Audio audio codecsring tonesMP3

Wireless GSM / GPRS modemUMTS / 3GBluetoothFM tunerUSBGPSRF-IDWLANDVB tuner

Wired USBStorage Removable Flash

Small HDDfixed flash

SW features Setup & ControlInstant messagingPDAJava2-D game

Video Mpeg2Mpeg4H264DivX

3

5


Convergence of digital consumer products

MASTERBEDROOM

portable display

KITCHENSTUDY

wireless LAN

KID’S BEDROOM

broadband

camera

LIVING ROOM

Media Server(DVD+RW/HDD

TV-to-TV link

RF remote control

home theater audio

INTERNET

Internet radio

The connected home

6


Some of today’s cars … ☺

http://www.aide-eu.org/pdf/aide_nf_050120_engstroem.pdf

4

7


Convergence of digital consumer products

Consequences:Large number of use cases

Increasingly complex use cases

Fast changing use cases with new applications appearing

Format updates at a much higher rate than the device replacement rate

Uncertain and diversified markets– Late / changing product specs, short product life cycles– Different customers / tiers have different requirements

Move from implementations in hardware to software to cope with the variation and changes

8


2 MB64 KB1 KBNo SW

Codesize

1 KB

10 KB

100 KB

1 MB

10 MB

Source: Philips Consumer Electronics

1985 1990 1995 2000

TV

1975 19801970

← Moore’s law for memory (10x every 5 years)

Exponential growth of SW in consumer products

2005

100 MB10x software

increaseevery

6-7 years

30 MB

5

9


Consumer electronics

CharacteristicsCost pressure (< $100 for electronics of large TV)

Low power consumption (no fan / mobile)

Large series (> 0.5 million pieces)

Robustness (no hazards, no reboots)

Both control and signal processing

Real-time constraints (no loss of data, guaranteed response)

Increasing requirements for computation & communication (more functions, higher resolutions)

10


Consumer domain demands SoC solutions

Highly integrated Systems-on-Chip to satisfy constraints on– Cost– Power consumption– Form factor– Ease of system integration

Enabled by large volumes– To amortize high NRE of SoC development– Need to target sufficiently large market

Optimized implementations with scarce resources– Memory, bandwidth, compute cycles

6

11


Max. 1080p@60hz

Hybrid TV system

NXPNXPPNX8541PNX8541

HybridHybridTunerTuner

DDRDDR64 MB64 MB

FLASHFLASH32 MB32 MB

DVI/HDMIDVI/HDMI DIGITAL DIGITAL AUDIO OUTAUDIO OUT

DIGITAL DIGITAL AUDIO INAUDIO IN

AudioAudioAMPAMP

Channel Channel DecoderDecoder

DVI/HDMIDVI/HDMI

Complete one chip TV:•Cost sensitive midrange market

•Connectivity,OSD

•Hybrid source decode

•De-interlacing

•Audio/Video processing

•Some video featuring

Add on Picture Quality booster•Halo reduced HD Natural Motion

•LCD Motion Blur Reduction

•Display color and Contrast enhancements

NXPNXPPNX5100PNX5100

HD MJC, HD MJC, 1080p@120Hz1080p@120HzColourWaveColourWave

Full up conversionFull up conversionMotion BlurMotion Blur

DDRDDR128 MB128 MB

PNX5100PNX5100

Up to 1080p @120hz

13


Key industry trends – More Challenges !

Cost of system design &integration is getting out of hand

– Hundreds of man-years for HW/SW system– Diversity of products

Increasing complexity– At application, system, HW, and SW level– More (sub-)systems on one SoC– Single company cannot excel in all domains

Loosing grip on product quality– Exploding costs for verification– Degrading reliability and predictability

More (programmable) cores in single SoC– Multi-core programming environments & debug

0.35µ0.25µ0.18µ0.15µ0.12µ0.1µ

Log

Scal

e

Moore’s Law

Design Productivity

Software Productivity

DMAC

5x S P I5x S P I

4x I2C

AXI2VPB

MC-E BI SMC

2xS Dcard2xS Dcard

Interrupt ctrlGP IO

Irda -F IR

E XTINT

I2SI2S

5x UART5x UART

Mis c reg s3x timer

Ram-bas ed Display Eng ine

VDE

RAM-lessColor LCD

controller PL110

PCM/IOM2PCM/IOM2

AXI2MMIO

TmVideoTM3270 350MHz

TV-out

2xTV DAC

WDRU

Periphera l mAXI (32-bit, 117 MHz)

RTC

AXI2VP B

IP C

Video &Image

proces sor

Memstick Mag ic GateKeyboard

US BOTG

TouchscreenADC

DMA PL080 interfa ceDMA PL080 interfa ce

2 x CCP2

2x RD16025C1Audio DS P

175MHz

Wasa bi L2 system cache (64-bit, 351 MHz, 512 kbyte S RAM)

L1 64+128kB2xL1 16+16kB

PWMDAC Dacctrl

DisplayRenoir

LML

IOM2

Interrupt ctrl

NDF -E CC

128kB BootR OM

AXI2AHB

Debug E J TAG

VideoRenoir

MBX HR+ VGP

Video Conc. (117MHz)

Concentra tor (117MHz)

CGUPLL

Osc

2x timer

2x IIS inARM1176351MHz

32+32 kB L1 cache

I RW D P

VFPHPM

4k+4kTCM ETM

J og Dia lS CON

ETBTAPDAP

TP IU

Multi-core debug & trace

(CoreS ight) S tereo ADCS tereo DACS tereo DACA

FE

Dig . F ilterDig . F ilterDig . F ilter

2 x Mic B ias

S tereo HF Amp.

LML

MTU

IEC

2x RD16025C2Telecom DS P

208MHz

2xL1 8 +8kB

2x RD16025C2Telecom DS P

208MHz

2xL1 8 +8kB

Cellular/GPS Modem

AR M1156Modem Contr.

234MHz

2xL1 32+32kB

AR M1156Modem Contr.

234MHz

2xL1 32+32kB

E VP E mbedded Vector P rocess orVD32040, 208MHz

OTP APC

System Power Mgt(P owerWise)

PrototypeExtension

2 x CS I-2

para llel

DS Iseria l

DBI-29-bit

DP I-224-bit

Mux

Imaging & Video Subs ystem

3DEngine

Peripheral Subsys tem

FRU

M

HPM

M M M M M M M M

M M M

M

MM3

MM

MMM

SSS

IP2032S DRAMcontroller

S SS

IP2032S DRAMcontroller

S

DCA?

S PMU

HDP

CAEGPADCADC

H.264Accelera tor

Mux

AMU?

2xIIS out

2xTS R

ARB

SW

Verification

7

14


Design Solutions

NXP requires a design process that isPredictable in time and performance

Efficient and high quality

The key elements of such a design process areRaising the level of abstraction– System Level Design, System Integration and Verification

High level of re-use– IP reuse (HW, SW)– Verification reuse– Architecture reuse (HW,SW, appl.tasks) Nexperia platforms

Integrated design environments– Automation of design flow Builder tools

15


Outline


Abstraction Levels

Functional Modeling


Summary

8

16


Func

tiona

l ver

ifica

tion

Design abstraction levels

High level executable spec

Specification capture

HW/SW partitioningArchitecture selection

HW model(TLM)

SW(low level)

SW (code)HW (RTL)

Compile& Optimize

Synthesize & Optimize

Synthesize & Optimize

Function

Architecture(TLM)

Implement’n(RTL)

HW design SW design

T1 T2 T3 T4

mem

CPUSW

HW

mem

CPU

SW

HW

17


Design abstraction levels – System-AMS

Functional

Architectural

Implementation

Specification

SystemC

Digital SystemInterfaceA(MS) DRF

VHDLVerilog-A(MS)

missinginteractions

C/C++Simulink

SystemC-AMS

9

18


Outline


Abstraction Levels

Functional Modeling


Summary

20


NXP SoC Example (simplified view)

On-chip interconnect

Shared off-chip memory

subsystem

Applicationsubsystem

Audiosubsystem

Image & Videosubsystem Radio

subsystem

Connectivitysubsystem

MP3

AC3

MPEG-4

H264

UMTS

WLAN

Bluetooth

USB

Linux

A SoC is composed of coarse-grain SubSystems

10

21


SoC Level Functional Model

Why do we need a functional model?Functional verification of algorithm

Single model for HW and SW parts.Explore algorithmic tradeoffs

Estimate resource requirements– Computational load, Communication load

Audio Image & Video Radio

MP3AC3

MPEG-4H264

UMTSWLAN

Connectivity

BluetoothUSB

22


SoC Level Functional Model (toplevel)

Audio

Image & Video

Radio AC3

MPEG-4

WLAN

LCD

demux

Control

PHY: ~ 10-15K Loc ~ 5K Loc

~ 10 - 15K Loc

~ 15 - 30K Loc

Difficult to create an executable SoC level functional model

Each sub-function contains hundreds of sub-blocks– Functional decomposition, Interfaces

Characteristic per functional sub-system differ– Different semantics needed

• Dataflow, Process networks, Discrete Event, State Machines– Different algorithmic tradeoffs

11

23


SoC Level Functional Model – Use CasesMany (complex) application use cases to handle

Audio

Image & Video

Connectivity AC3

H264

USB demux

Control

LCD

AudioImage & Video

Radio MP3

H264

UMTS

LCD

Control BluetoothConnectivitydemux

Audio

Image & Video

Radio AC3

MPEG-4

WLAN demux

Control

LCD

Audio

And many more ……

24


SoC functional model - Hurdles

Different Models of Computation (semantics)

Single functional model too complex to handle by single designer

Limited tool support

Many application use case to cover– “All in one” functional model not preferred

IP Re-use, platform based design

Many design teams involved– Multi site, Multi culture

Solution : Divide & Conquer approach

12

25


Functional Modeling at IP / Sub-System Level


MP3

AC3

MPEG-4

H264

UMTS

WLAN

Connectivity

Bluetooth

USB

Benefits of multiple functional models:

Complexity can be handled more easily

Optimized tools available for implementations

Specific implementation technology– Domain specific, single semantics

Specialized domain know-how (e.g. competence centre)

Different life-cycles re-use

26


Functional Model Refinement


MP3

AC3

MPEG-4

H264

UMTS

WLAN

Connectivity

Bluetooth

USB

Functional refinement directly to implementation level

On-chip interconnect off-chip Mem. ctrl

Refinement (RTL, C)

13

27


Functional RefinementCode-generation & Co-simulation

Image & Video

MPEG-4

H264

Radio

UMTS

WLAN

CodegenerationC-code, HDL

Radio

UMTS

WLAN

Co-simulationVerification

TesbenchHDL code

28


Functional Modeling – Multimedia Domain

An interface centric design approach– Communicating tasks based on KPN

– Optimal SW and HW interface types

Aim: Close gap between specification and implementation

TTL Task Transaction Level interface:– Parallel application models

• Executable specifications– Platform interface

• Integration of HW and SW tasks

Mapping technology– Structured design & programming Platform Infrastructure

AT SKS

Task Task

Task

MappingTTL

TTL

T4T2T1

T3

SW HW

[CODES04]

14

29


Example TTL based designsSmart Imaging Core

ARM 9xxCPU

SW Shell

HW Shell

HLAMLATTL API

TTL interface

Interconnect

SW ShellSmart ImagingCoprocessor

LLAs

MotionSegmentation

Motion EstimatorCoprocessor

VLIW

EmbeddedMemory

TTL

VideoInput

HW Shell TTL

MemoryCtrl Peripherals

Ext. SDRAM

[CODES05] , [DAES06]

30


Functional modeling - SimulinkBluetooth - EDR

Started with Simulink built-in models.

Developed a complete TX chain, including analog/RF blocks.

– Simulated the transfer function of the modulator and verified it against the Bluetooth standard specification

Converted the design into fixed-point format .

– Verified the functionality of the fixed-point design against the Bluetooth standard.

Generated (manually) a bit-compatible RTL description of the Simulink fixed-point model.

Evaluated the modulator on an FPGA platform.

Next step: HDL generation directly from Simulink

15

31


Functional modeling - ADS/PtolemyWireless LAN radio system

Functional model used as testbench for circuit design

32


What’s next after functional modeling?

Functional to implementation problems

SoC integration happens at RTL / C level– Complex and error prone– Iterations are not possible (first implementation/configuration that work

instead of best/optimized one)

Main usage of the Implementation level is for pre-silicon verification– But complete system is hard to simulate/verified all together

SoC integration at the implementation level introduces a big gap– Complex and error prone– Iterations are not possible (first implementation that work instead of best one)

An intermediate step before implementation is required

Architecture level– Main usage is SoC integration, analysis and debug

16

33


Outline


Abstraction Levels

Functional Modeling


Research challenges

Conclusions

34


Architectural Level – Key concepts

Abstraction– Increasing block granularity

• Gates (80’s), HDL (90’s), IP blocks (2000), SubSystems (2010)– From RTL to TLM (Transaction Level Modeling)

• but TLM covers only HW architecture, all system aspects need to be modeled together (i.e. architecture, application, constraints, etc)

Separation of concerns– Computation / Communication / Cost– Behavior / interfaces

Refinement– Synthesis and transformation techniques

Standards– OSCI (SystemC and TLM standards)– SPIRIT (IP-XACT)

RTL

Gate level

TLM

17

35


Architectural model => Virtual prototype

SystemPre ValidatedSpecification Virtual

Platform

SystemValidatedIC design Fab Demo

Board

System IntegrationHW dependent SW

Observability / Controlability / Debuggability

Technology Implementation:

Available early in dev. cycle

Enables early HW/SW co-design & co-verif.

HW/SW architecture & Impl. problems identified early

Short system bring-up time

36


But more than one architectural model is required

System-level performance verification

SW development and optimization

Functional partitioning and relative performance exploration

Interconnect and memory hierarchy dimensioning

System-level functional verification

HW development and optimization

timeline

SoC level Specification

IP / Subsystem level Implementation

SoC level (pre-silicon) Verification

Use-case driven approach

Different activities per design phase – Specification: exploration and dimensioning (SoC level)– Implementation: SW and HW development and optimization (IP and SubSystem level)– Verification: functional and non-functional verification of both HW and SW together

Activities have different requirements

18

37


Different use-cases, different requirements

x102

x103

x103

x102

x103

x104

x102

x104

RTL speed

up

HW dependent

Middleware

Application



HW development and optimization



Functional partitioning and relative performance estimation

Use-case

Very accurate performance and power estimations

Representative (worst-case) scenarios

HW/SW integration and verification (complete SW stack)

Extensive verification of scenarios

VP as a system-level test-bench for the HW IP

High Level Synthesis / RTL co-simulation (transactors)

Low-level drivers, HW abstraction layers (HAL)

Must be very optimized

Complex algorithms and codecs (H264, MP3, UMTS, AES etc)

SW platform services

End-user SW applications (platform services based)

Multicore debugging

HW architecture dimensioning

Focus on: bandwidth, latency, buffering, arbitration policies, etc

Enable extensive architectural exploration (what-if scenarios)

Focus on: task mapping, task scheduling, memory allocation, resource allocation, etc

Description

Absolute ±1%

Absolute ±10%Fully

functional models

Absolute ±10%

Absolute ±1%

Absolute ±10%

Absolute ±20%

Fully functional models

Absolute ±10%

Relative (fidelity)

Mixed abstract

performance and

functional models

Timing accuracy

Behavior accuracy

38


Different requirements, different models?

In an ideal world one model fits all – Ultra fast models + 100% cycle accurate + push-button availability

Unfortunately today we still need the right model for the right use-case…but one model per use-case is an overkill

– Huge effort to create and maintain every model– How to assure consistency between models?

Model reuse and refinement is a must…but modeling is a multidimensional problem

– High speed models contains very little time information– Very accurate models are typically slow and are difficult to create– No clear refinement paths from one model to another

And different types of models have different particularities– Processing units (CPU, DSP, etc)– Interconnects (busses, bridges, routers, etc) – Memory subsystem (L1-L2 cache, memory controllers, memories, etc)– Peripherals (IO blocks and slave HW accelerators)

SpeedAccuracy

Effort

Getting to the right model is the critical task

19

39


Modeling concepts

Minimizing the modeling effort– Library of predefined building blocks to compose IP models– Well defined methodologies and guidelines– Standard set of IP interfaces to assemble IP models (avoid adaptors)

Modeling for speed– Minimize the number of simulation events / context switches– Coarse grain computation and communication – Binary translation techniques for processors / host-code emulation techniques

Modeling timing– Accurate timed models are very hard to create– Approximated timed models are easier (but when it is good enough? )– Define accuracy windows, where the window size depends on the use-case

Refinement– Interfaces/Communication refinement – Behavior/Computation refinement – Cost (timing) refinement

Being tackle by OSCI TLM 2.0 standard proposal

Still ad-hoc, proprietary solutions

[TLM]

40


Abstraction Levels with SystemC

CPU

Interconnect

Memory

F1 F2Architectural

level

Implementationlevel

Functionallevel

F1 F2 F3 F4

HW coproc

F3 F4

CPU

Interconnect

Memory

HW coproc Signal level

communication

Transaction level

communication

Message level communication

send()recv()

write(address)read(address)

20

41


time0 1 2 3 4 5 6 7 8

UTT1 T2

(T) transaction (function call)

LT T1T2

ATrequest1 request2

response1 response2

CA

address1

data1

address2

data2

status1 status2

OSCI TLM 2.0 modeling styles

42


How many models do we need?

Fully functional models at the LT, AT level (Proc. IA ISS)

Fully functional models at the CA level (Proc. CA ISS)

Fully functional models at the LT level (Proc. IA ISS)

Fully functional models at the CA level (Proc. CA ISS)

Fully functional models at the UT, LT level (Proc. IA ISS)

High-level tasks

Mapping technology

Traffic generators

Processor units





Functional partitioning and relative performance estimation

Use-case

High-level tasks

Mapping technology

Data sinks

Peripherals

Functional models (CA), protocol specific

Functional models (AT), protocol independent

Interconnects

HW dependent

Middleware

Application

Memory subsystems

Buy, outsource In-house creation

21

43


Creating efficiently functional IP models

LT model

IP structure design tools

IP functionality design tools

RTL extractiontools

CA model

AT model

IP modeling libraries and methodology

+Standard modeling

libraries (SystemC, TLM, SCV)

synthesistools

IPspec

RTL HDL

2 functional models LT and CA, but…Time information on LT models can still range quite a bit

– Optimizations to improve speed– Refinement towards AT

CA models are not yet TLM but cycle-callable signal-level

VHDL, Verilog

Automatic generation

Automatic generation

Communication and computation refinement

44


IP modeling libraries and methodology

Objectives:

Reduce the modeling effort and learning curve for new model developers

– Quickly create the most common parts of the IP model using building blocks

Enable model reuse and refinement – Add details gradually (both communication and computation) – Separation of concerns applied to modeling

Improve configurability of models

– Change model internals during construction/elaboration time

Align with industry standards – OSCI TLM 2.0 & IP-XACT 1.4 IEEE 1666 SystemC

TLM 2.0 SCV

SCML

GMFL IF adaptors monitors

22

45


CoWare SCML

Methodology for model re-use – Use-case determine for bus model– Re-use peripheral model for multiple use-cases

Separation of behavior, communication and timing

Focus on communication refinement – generic interfaces + specific adaptors

Simple modeling pattern supported by a library of predefined blocks– SystemC Modeling Library (SCML) http://www.coware.com/solutions/tlm.php

46


NXP GMFL

Generic Modeling Features Library

Library of predefined blocks built on top of SCML

Extend and complement SCML capabilities – More methodology and guidelines

Focus on behavior modeling and refinement– Explicit synchronization, data and control flow

Key concepts are:

Hierarchical modeling– Structured, reusable code– Closer to HW designers

Dynamic layout– Add/remove functionality during elaboration– Block refinement

Design and code-generation tool

fB

fA fC

Specialized portsBehavior blocks

IP core

fB

Sync. & storage channels Generic core interfaces

Time annotations f User defined functionality

t t

t

parent sc_modulechild sc_modulechild sc_module

child sc_module

Rd frameProcessWr frame

T frame

Loop {Rd pixelProcess

Wr pixel }

T pixel

23

47


Functional design tool (3rd party)

IP structure design tool

import

SystemCcode-generation

NXP GMFL design and code-generation tool

48


Abstract (dynamic) performance simulations

App. use-caseControlrun-time

reconfiguration

PerformanceCharacterization

Requirements, constraintsApp. use-case

ModelApp. use-case

ModelApp. use-case

model(s)

SoC modelSystemC AT

SystemC CARTL

Tracing & visualization(analysis views)

mapping

monitoring

Stimuli generationCMU

24

49


Application use-case modeling and mapping

SoC infrastructure model

SystemC AT

SystemC CARTL

TLM 2.0

F1

F2

Scheduler Traffic initiator

CMU

Executable application use-case model (simple semantics)

– Synchronization & data communication– Dynamic data dependencies– Constraints (throughput, latency, etc)

Smart Traffic Generators (STG)– Direct mapping from app. use-case models– High level semantics adopted to bus protocol

traffic– Possibility to simulate

• function/data dependencies • Synchronization between STG• Scheduling / interrupts / preemption

– Generic interface + specific adaptors

Configuration Manager Unit (CMU)– Multiple use-cases can be mapped on a STG– CMU on charge of use-case switching

F3

F4

TLM 2.0

Scheduler Traffic initiator

Bus adaptor

Bus adaptor

STG STG

50


Outline


Abstraction Levels

Functional Modeling


Summary

25

51


Summary

SoC design challenges require moving up in the abstraction level and exploit re-use at all levels

Abstraction levels– Multiple domains (digital, analogue, RF) – Multiple languages (UML, C++, Simulink, SystemC, VHDL, Verilog-AMS, etc)

Functional modeling divide & conquer– Domain specific functions, different semantics, different algorithmic trade-offs– Multiple functional use-cases – Most tools provide a path to implementation

An integration level above implementation is required Architectural Level– Architecture model => Virtual prototype– Different architectural use-cases with different requirements => the right model for the

right use-case– Getting to the models is still the critical task => how to tackle this

• IP Modeling methodologies and libraries

• Automatic generation from different tools

52


References

[DAC2000] E.A. de Kock, G. Essink, W.J.M. Smits, P. van der Wolf, J-Y. Brunel, W.M. Kruijtzer, P. Lieverse, K.A. Vissers; “YAPI: Application Modeling for Signal Processing Systems “ in Proceedings of the 37th Design Automation Conference, Los Angeles, 2000[CODES04] Pieter van der Wolf, Erwin de Kock, Tomas Henriksson, Wido Kruijtzer, Gerben Essink, “Design and Programming of Embedded Multiprocessors: An Interface-Centric Approach”, Int. Conf. on Hardware/Software co-design and System synthesis, September 2004[CODES05] Wido Kruijtzer, Winfried Gehrke, Victor Reyes, Ghiath Alkadi, Thomas Hinz, JörnJachalsky, Bruno Steux; “The Design of a Smart Imaging Core for Automotive and Consumer Applications: A Case Study” in Int. Conf. on Hardware/Software co-design and System synthesis, September 2005[DAES06] Wido Kruijtzer, Victor Reyes, Winfried Gehrke; “Design, Synthesis and Verification of a Smart Imaging Core using SystemC” in Design Automation for Embedded Systems, An International Journal from Springer, Volume 10, Numbers 2-3, September 2006, pp. 127-155(29). Special Issue on SystemC-based System Modeling, Verification and Synthesis. DAC07: Slider[DAC2007] Walter Tibboel, Victor Reyes, Martin Klompstra, Dennis Alders ; “System-Level Design Flow Based on a Functional Reference for HW and SW” in Proceedings of the 44th Design Automation Conference, San Diego, 2007[SCML] http://www.coware.com/solutions/scml_kit.php[TLM] http://www.systemc.org/downloads/standards/[ESL book] Brian Bailey, Grant Martin, Andrew Piziali, “ESL Design and Verification: A Prescription for Electronic System Level Methodology” The Morgan Kaufmann Series in Systems on Silicon

Modelling of Systems on Chip - McGill...

Documents

Transcript of Modelling of Systems on Chip - McGill...