Hardware/Software Codesign of Embedded Systems

1. Hardware/Software Codesign of Embedded Systems Interface System on Chip Voicu Groza School of Information Technology and Engineering Groza@SITE.uOttawa.ca

2. Presentation Outline • Hardware-Software Codesign • HW-SW Interface • System-on-Chip

3. High level system description CODESIGN TOOLS HW SW VHDL C HW synthesis compiler ASIC/FPGA PROM HW/SW CoDesign Utopian View • Codesign tools automatically produce an optimized design from some initial high level specification!!!???? • Realistic goal: to incorporate the support for shifting functionality and implementation between HW & SW, with effective and efficient evaluation. The prototype is the output, based on currently available platforms (software compilers and commercial hardware synthesis tools). • Codesign does not aim to reinvent the wheel of system design, but the necessary flexibility must be effectively incorporated.

4. HW/SW CODESIGN Classic Design = Applying Concurrent Engineering techniques in designing complex HW/SW products HW SW HW SW • Combined • Concurrent • Cooperative • Unification Design of HW/SW

5. HW/SW INTERFACES Analysis of Constraints and Requirements System Specification Hardware/Software Partitioning Hardware Description Software Description HW Synthesis & Config SW Generation & Parameterization Config. Modules Interface Synthesis SW Components HW/SW Interfaces HW Components Hardware/Software Integration and Cosimulation System Evaluation Integrated System Design Verification

6. HW/SW Interface CFSM Events Event Implementation Synthesize Glue Between IPs

7. HW/SW Interface Synthesis

8. type yow { byte r, byte s } Synthesize Glue between IPs A B Concrete IPImplementations • At system level, A and B are abstract • In implementation, A & B are concrete • Concrete IP have different interfaces • May map to either HW or SW • To make IP integration effective, must synthesize interface HW IP A B OR SW A B

9. type yow { byte r, byte s } Glue Synthesize! Glue ProtocolSpecificationsfor Concrete IPs Synthesize glue between IPs Abstract IP A B Concrete IPImplementations HW IP A B OR SW A B

10. process mapping communication mapping A Vision for System Design USB Proc Proc ASIC System Bus Memory DSP Wireless

11. HW/SW Interface • Three classes of partitioned CFSMs: • SW: mapped to software • HW: mapped to hardware • MP: mapped to micro-controller peripherals • RTOS functions: • Enable communication between SW-CFSMs and SW-CFSMs, HW-CFSMs, MP-CFSMs • define emits and detects using • memory, • I/O ports and • interrupts • Coordinate SW - CFSMs • keep track which SW-CFSMs are ready to execute decide which one to execute

12. Events: SW to SW • For every event, RTOS maintains • global values • local flags x CFSM2 x emit x( 3 ) detect x CFSM1 CFSM3 x 3

13. Events: SW to SW • Implement atomicity by double buffering: • always read from frozen • others always write to live • at the beginning of task execution, switch CFSM live frozen

14. Event Implementation • SW to HW • allocate I/O port bits for value and occurrence flag • write value to I/O port • create a pulse on occurrence flag • SW to/from MP • use emit, detect functions from the library

15. Events: HW to SW • Event can be polled or driving an interrupt • For polled events: • allocate I/O port bits for value, occurrence and acknowledge flags • generate the polling task that acknowledges and emits all polled events that have occurred • For events driving an interrupt: • allocate I/O port bits for value, • allocate an interrupt vector, • create an Interrupt Service Routine that emits an event

16. Sender Receiver A B C Sender’s domain Channel’s domain Receiver’s domain Interfaces among Partitions • Automatically generated in both HW and SW (RTOS) • Hardware: standardized strobe/data protocol (corresponding to the event/value primitive) • Allows one to use hand-designed modules (following the interfacing convention)

17. Example of Interface: HW to SW ack HW SW HWtoSW x y - 1 / 0 (11 + 0 -) / 0 x - 0 / 1 y 0 1 ack 1 0 / 1 x ack / y

18. Events: Interrupts R T O S X IRQ X HW-CFSM SW-CFSM Two user-selectable choices: • Minimize blocking for other tasks and ISRs: ISR() { emit x } • Minimize latency for this event: ISR() { emit x execute SW-CFSM }

19. decoder decoder HW/SW Interface Architecture SW HW address bus HW->SW intr. event irq bus prot. conv. we HW->SW polled event, value mC oe decoder/mux SW->HW event, value data bus

20. Micro-controller peripherals • Custom HW (fully programmable, expensive) • On-chip or off-chip peripheral (partially programmable, inexpensive) A/D CPU RAM Timer EPROM I/O ports

21. Peripheral modeling approach • Ideally: implement specified function using peripherals (if possible) • Currently: use three models • Behavioral (Ptolemy) model for co-simulation • CFSM model for RTL co-simulation and rapid prototyping • C model for implementation (programming and interfacing with the peripheral) • Parameters customize all models simultaneously (plug-in replacement of abstraction levels) • Synthesizable CFSM model key to limited re-targetability

22. Peripheral modeling approach • The user must • decide in advance which functions may need to be implemented on a library peripheral • choose the best fitting model from a library • co-simulate to decide implementation (SW, custom HW, peripheral, …) • The co-design environment takes care of: • synthesizing in SW or HW • extracting peripheral programming SW from library (may be partially micro-controller independent) • interfacing transparently

23. Communication Synthesis Communication synthesis Behavioral Description Mapping of Behavior to Architecture Architectural Description Functional Prototype Co-Simulation

24. ProcessorY ProcessorX consumer producer Net Comm. Chip scheduler scheduler portB protocol portA protocol consumer producer on-chip Net Comm. inter face glue portA Net dev. driver Net dev. driver initiali- zation initiali- zation portB message router message router synthesized sw/hw hardware library Communication Infrastructure Designer maps • processes to processors and • messages to busses/protocols Message1 Net / Message1 software library

25. System on a Chip Rationale Typical SoC Core-Based Design

26. Systems-on-chip • Started with the idea of integrating all components in a board into a single chip. • In the last 20 years the technologies implementing embedded systems evolved from microcontrollers and discrete components to fully integrated systems-on-chip (SoC) • SoCs and related technologies are the engines of embedded systems in the foreseeable future. • To increase the productivity for future designs, the approach of reusable components was adopted = intellectual property cores (IPs).

27. Why SoC? • System architects cannot afford design restarts. • HW and SW design teams cannot afford n design iterations or to learn all the details about every potential IP core. • System managers cannot afford to reinvest in completely new tools. • IC business managers cannot afford missing customer market windows or foundry schedules. • Industry shifts from ASICs to systems-on-a-chip.

28. SYSTEM-ON-A-CHIP (SOC) Rationale • Industry shifts from ASICs to systems-on-a-chip, • New concepts, such as design re-use, Intellectual Property (IP) utilization, and system-level co-design have been widely embraced, while practical solutions have yet to be developed. • System architects cannot afford design restarts. • Hardware and software design teams cannot afford endless design iterations or to learn all the details about every potential IP core. • EDA system managers cannot afford to reinvest in completely new tools. • IC business managers cannot afford missing customer market windows or foundry schedules.

29. SoC Architecture • Heterogeneous processors • those used to run the end application and • those dedicated to execute specific functions that could have been designed in hardware. • Application-specific Intellectual Property (IP) cores • Communication interconnect.

30. SOC Design • Language-independent methodology for system specification • Accurately capture a concept into an architecture-independent specification • Easy definition of blocks and modules • Facilitate concurrent execution of blocks + separate the behavior and communication of those blocks. • Provides the ability to animate the system specification and validate/debug the required product functionality prior to costly design implementation. • The specification allows existing modules, with different abstraction levels, to be re-used. • A complete test bench, for checking the system, is developed at this stage. • Open SystemC community recommends to using C and C++

31. Optimal SOC Design-to-Implementation ProcessTop-Down Design Flow • design (capturing and animating the system specification), • co-design • hardware/software partitioning • interface design • co-simulation • co-implementation (design refinement in parallel and co-verification) • IP re-use.

32. SOC Co-Design • Different architectures (such as processor cores: ARM, DSP) are selected for possible implementation, to explore various HW/SW partitioning tradeoffs. • Select the corresponding communication mechanisms (memory mapped I/O, fast interrupt request etc.,) for a given target core • Generate the corresponding software device drivers and the corresponding hardware glue logic to allow for quick exploration of different partitioning schemes. • System verification at different abstraction levels. • Un-timed models • Instruction accurate models • Bus cycle accurate models • Virtual prototype at the earliest stage of design => faster simulation. Traditional hardware-software co-verification with the hardware in HDL code running in an RTL simulator

33. SOC Co-Implementation • Once the HW/SW partitioning is agreed to, the different SW development teams and HW design teams work in parallel to further optimize the software and gradually refine the hardware while constantly remaining consistent with the original system specification. • Changes in SW are communicated to the HW team and resultant changes in the HW are made. The converse should be true for HW originated changes. • The output of the HW portion is synthesizeable RTL and the process flow therefore allows co-verification of HW and the actual binary code of the software running on a model of the processor core. • IP re-use at all levels (silicon IP, gate level IP, RTL IP)

34. SYSTEM-ON-A-CHIP (SOC) Design Forms • vendor design • partial integration • desktop design SOC Vendor Design • An ASIC vendor or a design services group designs the core and ASIC to meet a customer’s functional specification. • Gives the system designer little or no control over the design schedule and may result in a longer time to market and less design flexibility • Can lead to the lowest production cost per die • May result in high engineering costs, to be used for high-volume applications.

35. SOC Partial Integration • The system designer creates most or all the ASIC gates, and the ASIC vendor designs and integrates the core with the customer’s ASIC logic. • Provides a more flexible division of labor, and the system designer has some control over the design schedule. • Dominant approach in the past SOC Desktop Design • Gives the system designer the most flexibility and enables the fastest time to market • The ASIC vendor designs the core, and the system designer builds the ASIC logic and integrates the core, using a standard ASIC design flow. • The ASIC vendor is no longer the design schedule gatekeeper. • This approach incurs the lowest engineering cost and is suitable for lower-volume solutions.

36. Intellectual Property (IP) Cores • Hard cores are provided as black boxes, usually in layout form in a given technology and with an encrypted simulation model. Examples of hard cores are microprocessors, phase-locked loops mixed signal blocks. • Firm cores are provided as a synthesized netlist in a hardware-description language (HDL), that is, after logic synthesis and technology mapping, but without layout information. These cores can be simulated and changed if necessary. • Soft cores are given as register-transfer level HDLs, and the user is responsible for its synthesis and layout. Usually along with the soft cores, the IP providers also supply synthesis and layout scripts and timing assertions.

37. Types of Cores • Synthesizable core • Soft core • Firm core • Hard core • Comes in a technology-independent high-level description language form. • The core’s lay-out is completely flexible, but its speed and density are limited by the characteristics of the ASIC cell library in which it is implemented. • Require ground-up synthesis, test, static timing analysis, and user verification. • Their flexibility limits their “drop-in” design usability and their ability to leverage performance and area optimization characteristics.

38. Synthesizable core • Soft core • Firm core • Hard core Types of Cores • Is a technology-dependent gate-level netlist. • May include a small amount of high-level technology-independent code that a designer can use to parameterize the core during synthesis. • Because of the core’s technology-dependent nature, its size and speed are more predictable than those of synthesizable cores. • The soft core’s layout is flexible, but floor-planning guidelines may be necessary to achieve performance targets.

39. Synthesizable core • Soft core • Firm core • Hard core Types of Cores • Comes in the form of an encrypted or abstracted black box that protects the core’s intellectual property content. • Designers incorporate a firm core into an ASIC design (in the same manner as a library element). • The ASIC vendor lays out the core, using a technology-dependent gate-level netlist. This provides flexibility in the chip layout process because the core form factor is not fixed. • A firm core’s size, aspect ratio, and pin location can be changed to meet a customer’s chip layout needs, and floor-planning guidelines assist the chip designer in making trade-offs. • The technology-specific nature of a firm core makes it highly predictable in performance and area. • Because layout uses a gate-level netlist, a firm core has the same routability as a soft core.

40. Types of Cores • Synthesizable core • Soft core • Firm core • Hard core • Is an encrypted or abstracted black box, which designers incorporate into an ASIC design in the same manner as a standard cell library element. • Have a fixed, custom physical layout. • The technology-specific layout allows maximum optimization in terms of performance and density. • Have the most limited vendor portability and greatest difficulty of reuse when moving to a new process technology. • May contain significant routing blockages (poor porosity), making the placement of other blocks and chip-level routing difficult.

41. DSP Processor External I/O DSP RAM MPEG Processor Bus Control Processor Peripheral Audio Decode System RAM IP-Based Design of Implementation Which Bus? PI? AMBA? Dedicated Bus for DSP? Which DSP Processor? C50? Can DSP be done on Microcontroller? Can I Buy an MPEG2 Processor? Which One? Which Microcontroller? ARM? HC12? How fast will my User Interface Software run? How Much can I fit on my Microcontroller? Do I need a dedicated Audio Decoder? Can decode be done on Microcontroller?

42. Issues Limiting SOC Ramp • Economics • Productivity • Process • IP Delivery & Reuse • Tools & Methodology • Manufacturing How do we move SoC Design from the pilot line to production ? Source:M.Pinto, CTO, Agere

43. Validating Designs • By construction • property is inherent. • By verification • property is provable. • By simulation • check behavior for all inputs. • By intuition • property is true. I just know it is. • By assertion • property is true. Wanna make something of it? • By intimidation • Don’t even try to doubt whether it is true • It is generally better to be higher in this list SOURCE: Alberto Sangiovanni-Vincentelli,University of California at Berkeley

44. State-of-the-Practice • DSP Tools: develop algorithms by creating and simulating block diagrams, and most generate C or HDL code: Matlab™ from Mathworks Inc., Signal Processing WorkSystem of Cadence Design Systems, COSSAP from Synopsys. State Diagram Entry Tools support system-level block diagram entry and simulation, Statemate Magnum/i-Logix, Stateflow/Mathworks HDL Simulators, Verilog-XL™ & Leapfrog™ VHDL of Cadence Design Syst, VCS and VSS from Synopsys, MTI from Mentor Graphics. Software Development Tools (IDE) compilers, real time operating systems, and various tools used to enable simulation and debugging with the instruction set simulator of the processor (WindRiver, ARM, etc.) Co-Verification Toolsof what have been already completely designed: CoWare N2C, Eaglei™ from Synopsys, Seamless CVE™ from Mentor Graphics,.

45. CANADIAN MICROELECTRONICS CORPORATION Rapid-Prototyping Platform

46. Stereo Web-TV STB TV Entertainment Based DVD Player Cam Corder Still Camera Voice Phone Video Phone VCR Video Game PC-1 laptop Telecom Based PC-2 PDA PC/Data Based Internet Access Printer Intercom Sprinklers Door Sensors Motion Detectors Utility Customization Window Sensors Toasters Appliance Based Security Based Video surveillance Light Control Ovens Climate Control Audio Alarms Smoke Detectors Clocks Home Networking SOURCE: Alberto Sangiovanni-Vincentelli,University of California at Berkeley

47. Conclusions • Computer-aided SW/HW Engineering (CASHE) framework/tools still “under construction” • Current combination of EDA/CAD tools • are too slow => distributed systems • have incompatible formats => too many translators • First integrated EDA environments for dedicated SoC applications • Codesign will become reality as soon as corporate entities recognize its full benefits

48. THE Conclusion • HW/SW Codesign for Embedded Systems is a “cut & paste” technology • To fit these parts in the big picture, one has to understand them, i.e., to know • Electronics, • Logic design, • Computer architecture, • Software engineering.

49. Problem: atomicity of transition TASK 1 detect x detect y TASK 2 emit x TASK 3 if detect x then emit y • TASK 1 detects y AND NOT x, which is never true • To avoid, need atomic detects