1. Winter-Spring 2001Codesign of Embedded Systems1 Methodology for HW/SW Co-verification in SystemC Part of HW/SW Codesign of Embedded Systems Course (CE 40-226)

2. Winter-Spring 2001Codesign of Embedded Systems2 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 Reference: L. Semeria & A. Ghosh, “Methodology for Hardware/Software Co-Verification in C/C++”, in ASP-DAC 2000

3. Winter-Spring 2001Codesign of Embedded Systems3 Methodology for HW/SW Co-verification in SystemC Introduction

4. Winter-Spring 2001Codesign of Embedded Systems4 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)

5. Winter-Spring 2001Codesign of Embedded Systems5 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

6. Winter-Spring 2001Codesign of Embedded Systems6 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 r e-using testbenches developed during system validation phase enabling hw/sw co-verification and performance estimation at very early stages of design

7. Winter-Spring 2001Codesign of Embedded Systems7 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,

8. Winter-Spring 2001Codesign of Embedded Systems8 Methodology for HW/SW Co-verification in SystemC Design Flow

9. Winter-Spring 2001Codesign of Embedded Systems9 Design Flow Functional Specification of the system Architectural Specification Mapping Refinement of Individual hw and sw blocks Synthesis for hw blocks Compilation for sw blocks

10. Winter-Spring 2001Codesign of Embedded Systems10 Methodology for HW/SW Co-verification in SystemC Processor Models

11. Winter-Spring 2001Codesign of Embedded Systems11 Processor Models Bus Functional Model (BFM) Instruction-Set Simulator (ISS)

12. Winter-Spring 2001Codesign of Embedded Systems12 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

13. Winter-Spring 2001Codesign of Embedded Systems13 Bus Functional Model (cont’d) SW HW SW C/C++BFM At early stages of the design In the later stages of the design SW HW SW ISSBFM Assembly

14. Winter-Spring 2001Codesign of Embedded Systems14 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

15. Winter-Spring 2001Codesign of Embedded Systems15 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

16. Winter-Spring 2001Codesign of Embedded Systems16 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

17. Winter-Spring 2001Codesign of Embedded Systems17 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

18. Winter-Spring 2001Codesign of Embedded Systems18 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

19. Winter-Spring 2001Codesign of Embedded Systems19 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

20. Winter-Spring 2001Codesign of Embedded Systems20 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)

21. Winter-Spring 2001Codesign of Embedded Systems21 Processor Model Bus Functional Model (BFM) Instruction-Set Simulator (ISS)

22. Winter-Spring 2001Codesign of Embedded Systems22 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

23. Winter-Spring 2001Codesign of Embedded Systems23 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)

24. Winter-Spring 2001Codesign of Embedded Systems24 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

25. Winter-Spring 2001Codesign of Embedded Systems25 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)

26. Winter-Spring 2001Codesign of Embedded Systems26 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

27. Winter-Spring 2001Codesign of Embedded Systems27 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

28. Winter-Spring 2001Codesign of Embedded Systems28 Methodology for HW/SW Co-verification in SystemC Implementation: 8051

29. Winter-Spring 2001Codesign of Embedded Systems29 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

30. Winter-Spring 2001Codesign of Embedded Systems30 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

31. Winter-Spring 2001Codesign of Embedded Systems31 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

32. Winter-Spring 2001Codesign of Embedded Systems32 Complementary notes: Assignments Take Assignment 8 Due Date: Saturday, Khordad 12th