Methodology for HW/SW Co-verification in SystemC

Winter-Spring 2001 Codesign of Embedded Syste

ms1

Methodology for HW/SW Co-verification in SystemC

Part ofHW/SW Codesign of

Embedded Systems Course (CE 40-226)


ms2

Topics Introduction Design Flow Processor Models Implementation: 8051 Conclusion

Reference:

L. Semeria & A. Ghosh, “Methodology for Hardware/Software Co-Verification in C/C++”, in ASP-DAC 2000


ms3

Methodology for HW/SWCo-verification in SystemC

Introduction


ms4

Introduction Shrinking device sizes => all digital

components on a single chip Software is traditionally fully tested after

hardware is fabricated => long TTM Integrating HW and SW earlier in the

design cycle => better TTM Co-simulation involves

Simulating a processor model along with custom hw (usually described in HDL)


ms5

Introduction (cont’d) Heterogeneous co-simulation

environments (C-VHDL or C-Verilog) RPC or another form of inter-process

communication between HW and SW simulators

High overhead due to high data transmission between the simulators


ms6

Introduction (cont’d) Recently HW synthesis techniques from

C/C++ are more investigated Eliminates C to HDL translation for synthesis

=> higher productivity Reduces translation time Eliminated bugs introduced during this translation

Easier verification by re-using testbenches developed during

system validation phase enabling hw/sw co-verification and performance

estimation at very early stages of design


ms7

Introduction (cont’d) In this paper, authors present

How hw/sw co-verification is performed in a C/C++ based environment

hw and sw are both described in C++ (SystemC)

Other C/C++ based approaches: PTOLEMY, and CoWare N2C,


ms8


Design Flow


ms9

Design FlowFunctional Specification

of the system

Architectural Specification

Mapping

Refinement of Individual hw and sw blocks

Synthesis for hw blocksCompilation for sw blocks


ms10


Processor Models


ms11

Processor Models Bus Functional Model (BFM) Instruction-Set Simulator (ISS)


ms12

Bus Functional Model (BFM) Encapsulates the bus functionality of a

processor Can execute bus transactions on the

processor bus (with cycle accuracy) Cannot execute any instructions

Hence, BFM is an abstract model of processor that

can be used to verify how a processor interacts with its peripherals


ms13

Bus Functional Model (cont’d)

SWSW HWHWHWSWC/C++ BFM

At early stages of the design

In the later stages of the designSWSW HWHWHWSW

ISS BFMAssembly


ms14

Design of the BFM Is a SystemC module

Ports of the module correspond to the pins of the processor

Methods of the module provide a PI (programming interface) to the software/ISS

They depend on the type of communication between hw and sw

BFM functionality is modeled as a set of concurrent FSMs


ms15

Memory-mapped IO Peripherals are located on a portion of CPU

address space BFM provided methods

void bfm_read_mem(sc_address, sc_data *, int) void bfm_write_mem(sc_address, sc_data, int)

SW (without ISS) calls these functions to access hw

When using ISS, SW calls device drivers. Device drivers are run in the ISS and at proper

time call these functions


ms16

Interrupt-driven IO An interrupt controller is implemented in

BFM It is made sensitive to the CPU interrupt lines

In case of an interrupt, the corresponding ISR is called

ISRs are registered by these BFM methods void bfm_register_handler(sc_interrupt,

void (*handler)(sc_interrupt))

Interrupts may be masked/change behavior using configuration ports


ms17

Configuration ports,Access to internal registers CPUs often have configuration ports for

Multiple modes of operation Multiple timers/serial modes Masked interrupts etc

BFM methods to access these registers void bfm_read_reg(sc_register, sc_data*, int nb) void vfm_write_reg(sc_register, sc_data, int nb)

BFM usually doesn’t model general-purpose registers of the CPU


ms18

Timers and Serial Ports Normally, controllers for these timers

and serial ports are implemented within BFM

They are configured using configuration ports and registers Previously mentioned functions are used

They may issue interrupts to the CPU


ms19

Performance Estimation Functions BFM keeps track of bus transactions

Can report number of clock cycles spent for each bus transaction

Reporting can be taken after each transaction or at the end of simulation

Tracking is enabled using void bfm_enable_tracing(int level)

level is used to define multiple levels of tracking

Even debug information can be produced by the BFM


ms20

HW/SW Synchronization Normal BFM methods are blocking

SW execution is suspended until the bus transaction is done

This essentially serialized SW and HW execution A flag can be set in the BFM to make SW

execute in parallel with HW i.e. BFM methods return immediately

SW can wait for a specific number of clock cycles by calling

void bfm_idel_cycle(int)


ms21

Processor Model Bus Functional Model (BFM) Instruction-Set Simulator (ISS)


ms22

Instruction-Set Simulator ISS: a processor model capable of

simulating execution of instructions Different types of ISS for different

purposes Usage 1: Verification of applications written

in assembly-code For fastest speed: translate target assembly

instructions into host processor instructions Is not cycle-accurate. Specially for pipelined and

superscalar architectures


ms23

ISS (cont’d) Different types of ISS … (cont’d)

Usage 2: Verification of timing and interface between system components

Used in conjunction with a BFM ISS should be timing-accurate in this usage

ISS often works as an emulator For performance estimation usage, ISS is to

provide accurate cycle-counting To have certain speed improvements, ISS should

provide necessary hooks (discussed later)


ms24

Integrating an ISS and a BFM ISS + BFM => complete processor model Cycle-accurate ISS + (already cycle-

accurate) BFM => cycle-accurate processor model

Typical units of an ISS Fetch, Decode, Execute Execute unit performs calls to BFM to access

memory or configuration registers Fetch unit performs calls to BFM to read

instructions


ms25

Integrating an ISS and a BFM (cont’d) For more complex architectures

(pipelined, superscalar) Other units must be modeled

Cache, prefetch, re-order buffer, issue, … Many units may need to call BFM functions

ISS may need to provide BFM with certain memory-access functions (discussed later)


ms26

Techniques to speedup simulation

Reduce activity on memory bus Most applications: 95% of memory traffic is attributed

to instruction and data fetches Memory access previously verified? => no need to

simulate it again during co-simulation Put instruction memory (and/or data memory) insideISS What to do for external devices accessing instr/data memory?

BFM must be configured to recognize them and call corresponding ISS method to access instr/data

ISS must provide the above methods ISS must implement a memory map, where certain addresses

are directly accessed, while others through bus cycles


ms27

Techniques to speedup simulation (cont’d) Turn off clocks on modules

All clocked components activate by clock edge

Most of time the component is not addressed => activation and simulation (even a limited part of each process) is wasteful => turn off clocks when not necessary

How to do it? BFM generated bus clock, only when devices on

the bus are addressed


ms28


Implementation: 8051


ms29

Implementation: 8051 Implementation of Synopsys dw8051 BFM and

cycle-accurate ISS Synopsys dw8051:

8-bit microcontroller Configurable, fully synthesizable, reusable macrocell industry standard for simple embedded application

smartcard, cars, toys, … Many IO modes SFR (Specific Function Register) bus interrupt ports (expandable to 12) up to 2 serial ports, in 4 different modes of operation up to 2 timers, in 3 different modes of operation


ms30

Implementation: 8051 (cont’d) dw8051 BFM

Fully developed in SystemC BFM supports

timer 1, mode 0,1,2 serial port 0, mode 0,1,2,3 external interrupts external memory accesses SFR accesses

dw8051 cycle-accurate model


ms31

What we learned today Ghosh et al co-verification strategy, using

SystemC, was presented C/C++ models are very efficiently compiled on

today architectures No overhead for C-HDL interfacing is introduced Performance estimates can be obtained from

model C++ allows use of OO techniques to create BFM

and ISS, which enables re-use of them for subsequent generations of the processor


ms32

Complementary notes:Assignments Take Assignment 8

Due Date: Saturday, Khordad 12th

Date post:	10-Feb-2016
Category:	Documents
Upload:	glenda
View:	46 times
Download:	1 times

Methodology for HW/SW Co-verification in SystemC

Documents