SoC Design Lecture 9: Platform Based Design. Shaahin Hessabi Department of Computer Engineering

Transcription

1 SoC Design Lecture 9: Platform Based Design Shaahin Hessabi Department of Computer Engineering

2 Design Methodologies TDD: Timing-Driven Design BBD: Block-Based B Design PBD: Platform-Based Design 2

3 Timing-Driven Design Symptoms requiring a shift from ADD to TDD methodology: Looping between synthesis and placement without convergence on area and timing Long turnaround times for each loop to the ASIC vendor Unanticipated chip-size growth late in the design process Repeated area, power, and timing re-optimizations Late creation of adequate manufacturing test vectors Caused by: Ineffective or no floor planning at the RTL or gate level No process for managing gand incrementally incorporating late RTL design changes into the physical design Pushing the technology limits beyond what a traditional netlist handoff can support Ineffective modeling of the chip infrastructure t (clock, power, test) t) during floor planning Mishandling of datapath logic 3

4 Benefits: Netlist handoff is well understood Timing-Driven Design (cont d) Flat-timing analysis / delay calculation is better supported by most of today s tools Test generation can be uniform and automatic Challenges: High-performance products require iterative loops (place&route timing --> synthesis) Flat methodology begins to fail as complexity increases (>150 kgates) Wire-load models are insufficient for high-performance or low-power designs Main technologies: Interactive floor-planning tools Static-timing analysis tools Using compilers to move design to higher abstractions with timing predictability 4

5 Symptoms when BBD is more appropriate: Block-Based Design Design team is becoming more application-specific, p and subsystems, such as embedded processing, digital data compression, and error correction, are required Multiple design teams are formed to work on specific parts of the design ASIC designers are having difficulty developing realistic testbenchestb Interface timing errors between subsystems are increasing dramatically Design team is looking for VCs outside their group to accelerate product development Designs employ a bus architecture processor-determined or custom Needs a block-level floor planner that quickly estimates RTL block sizes 5

6 Benefits Block-Based Design (cont d) Top-down design approach manages complexity of large designs Import of external processor cores supported Complex, parallel block design teams supported Challenges Process does not create a set of reusable components Constrained by design and re-verification of soft RTL block Limited availability of cycle-accurate and behavioral models Main technologies Application-specific, high-level algorithmic analysis tools Block floor planning Integrated synthesis and physical design 6

7 Symptoms when PBD is more appropriate: Platform-Based Design A significant number of functional design are repeated within and across groups,,yet little reuse is occurring between projects New convergence markets cannot be engaged with existing expertise and resources Functional design bugs are causing multiple l design iterations ti and/or re-spins The competition is getting to market first and getting derivative products out faster Project post-mortems have shown that architectural trade-off (HW/SW, VC selection) have been suboptimal ICs are spending too much time on the test equipment during production, thus rising overall costs Pre-existing VCs must be constantly redesigned Actions to be taken: block authoring; interface standardization; early co-design/co-verification 7

8 Benefits Platform-Based Design (cont d) Planned design reuse yields very high productivity (and lower costs later on) Can substantially shorten design cycles Enables quick derivative designs once the basic platform works Designs can be composed of diverse, specialized functions from multiple sources Large share of pre-verified components helps validation for complex designs Interface-based design promotes higher abstraction design and implementation Challenges Planned reuse requires significant up-front design planning Significant SW portions require extensive HW/SW co-verification Platform migration to new process technology requires re-characterization of VCs (hard and soft) and platform architecture Limited creativity due to predefined platform components and assembly 8

9 Main technologies Platform-Based Design (cont d) High-level, system-level algorithmic and architectural design tools and hardware/software co-design technologies Physical layout tools focused on bus planning and block integration VC-authoring functional verification tools 9

10 Comparing Design Methodologies Design characteristics Timing-Driven Design Block-Based Design Platform-Based Design Design complexity 5000 to 250 K gates 150 K to 1.5 M gates 300 K gates and greater Design level RTL behavioral / RTL Architecture, VC evaluation Design team small, focused multi-disciplinary multi-group, multi-disciplinary Primary design custom logic blocks in context, interfacing to system and bus custom interfaces Design reuse None soft, firm, and hard IP Planned firm and hard Primary optimization focus Synthesis, gate-level architecture Floor planning, block architecture Primary design gates and memory functional clusters, VCs granularity cores Silicon compatible system architecture Bus architecture none / custom custom standardized / multiple application specific Test architecture none / scan scan / JTAG / BIST / custom hierarchical, parallel scan / JTAG / BIST /custom 10

11 Comparing Design Methodologies (cont d) Design characteristics Timing-Driven Design Block-Based Design Platform-Based Design Mixed-signal none A/D, PLL functions, interfaces Verification level RTL / gate bus functional to cycle accurate RTL/gate mixed (ISS to RTL with HW and SW) Hardware/software none HW/SW functionality HW/SW interfaces only co-verification and interfaces Partitioning focus synthesis limitations functions Functions/communications Placement flat hierarchical hierarchical Routing flat flat hierarchical Timing analysis flat flat with limited hierarchical hierarchy Delay calculation flat flat hierarchical 11

12 Platform-Based Design Only the consumer gets freedom of choice; designers need freedom from choice (Orfali, et al, 1996,,p p.522) A platform is a restriction on the space of possible implementation choices, providing a well-defined abstraction of the underlying technology for the application developer New platforms will be defined at the architecture-micro-architecture boundary They will be component-based, and will provide a range of choices from structured- custom to fully programmable implementations Key to such approaches is the representation of communication in the platform model 12

13 The New System Design Paradigm Separation of function and architecture, of communication and computation Function: A function is an abstract view of the behavior of the system. It is the input/output characterization of the system w.r.t. its environment. It has no notion of implementation associated to it. 13

14 Architecture Terms An architecture is a set of components, either abstract or with a physical dimension, that is used to implement a function. Architecture platform: A fixed set of components with some degrees of variability in performance or dimensions i of one or more of its components Communication Communication provides for the transmission of data and control information between functions and with the outside world. Communication layers: Transaction: Point-to-point transfers between VCs. Covers the range of possible options and responses (VC interface). Bus Transfer: Protocols used to transfer data between two components across a bus. Physical : Deals with physical wiring of the buses, drive, and timing specific to process technology. 14

15 Design Flow and Architecture Template Template: an architecture with parameters and rules that define what is (not) allowed. Platform-based design flow: 15

16 System-on-Chip Platform Layered concept allows to Change the physical architecture of the SoC without affecting the application Add new services on top of existing architecture Changes in one layer affect only the layer itself and its interfaces 16

17 PC Platform The most successful application of platform concept for reuse. x86 ISA (makes it possible to re-use OS and software applications at binary level). fully specified set of busses (ISA, USB, PCI). legacy support for the ISA interrupt controller. fully specified set of I/O devices. Too rigid (and expensive) for embedded system applications 17

18 A fully defined architecture with Bus structure Clocking/power distribution OS A collection of IP blocks Architecture reuse Platform-Based Integration The definition of a hardware platform is the result of a trade-off process involving reusability, production cost and performance optimization. 18

19 Hardware Platform Hardware Platform: not only a fully specified SoC, but also a family of architectures that: share some common features, satisfy a set of architectural constraints imposed to allow the re-use of hardware and software components. The stronger the constraints the more component re-use but stronger constraints imply fewer architectures to choose from! Hardware platforms is not enough: Hardware platform has to be abstracted. Interface to the application software is API. Software layer performs abstraction: Programmable cores and memory subsystem with RTOS. I/O subsystem via Device Drivers. 19

20 Very little difference with top down design. Partitioning is known, so no partitioning step. Platform Based Design Part of the executable model is handed over to SW developer for optimization. HW and SW still modeled in one unified model. SW and HW people still work in parallel, refining and optimizing their designs. HW platform is built separately. This can be used as a virtual platform for the SW developers to develop their SW on. SW people can work in their preferred environment. Less concurrency in HW and SW development. Concurrency still possible: HW platform is delivered at a higher level of abstraction, on which SW people do development, elopment while HW people are further refining to lower levels of abstraction. 20

21 How Platform-Based Design Works? 21

22 Ingredients of a Platform Cores Processor IP Bus/Interconnection Peripheral IP Application specific IP Software Drivers Firmware (Real-time) OS Application software/libraries Validation HW/SW Co-Verification Compliance test suites Prototyping HW emulation FPGA based prototyping Platform prototypes (i.e. dedicated prototyping devices) SW prototyping 22

23 How to Build a Platform Architecture constraints for an integration platform: 1. Pick your application domain 2. Pick your on-chip communications architecture and structure (levels and structure of buses/private communications) 3. Pick your Star IP (e.g. processors) Processors: drag along detailed communications choices, e.g. processor busses 4. Dedicated memory access, etc. - ARM-AMBA, etc. Also limit e.g. RTOS 5. Pick application specific HW and SW IP 6. Other IP blocks not wrapped to the on-chip communications may work with IP wrappers. VSI Alliance VCI is a good choice to start with for an adaptation layer 23

24 Types of Platform stronger According to the strength of constraints on hardware Fixed Platforms Software-oriented: TI's OMAP TM, Philips Nexperia.. Application-specific: Ericsson s BCP, Configurable platforms Bus structure, multiple processors, programmable logic devices: Altera's Excalibur TM, Triscend s CSoC, Philips RSP, Cypress MicroSystems PSoC TM Programmable platforms Improv s PSA TM Jazz weaker 24

25 Triscend E5 CSoC Triscend: the pioneer in commercially providing Programmable SoC devices. Introduced in 1999, E5 chips are equipped with 8032-compatible processor; hence, suitable for control-dominated applications. Features: Performance accelerated 8051 core (10MIPS at 40MHz) Standalone operation from a single external memory (code + configuration) Up to 64Kbytes of on-chip, dedicated system RAM Up to 3200 Configurable System Logic (CSL) cells (up to 40,000 "ASIC" gates) Power-down and power-management modes Compliant to the "CSI Socket" interface, allowing soft peripherals to be used on other CSoC Families Two dedicated DMA Channels On-chip breakpoint unit provides sophisticated debugging capability Offers real-time debugging for hw/sw co-verification 25

26 Triscend A7 CSoC Industry s first 32-bit Programmable SoC, is based on ARM7TDMI RISC processor. Features: High-performance, 32-bit ARM7TDMI Processor Core Memory Interface Unit Flexible, glue-less interface to external memories (ROM, EEPROM, FLASH, SRAM, and SDRAM) 8-bit, 16-bit and 32-bit support Up to 2 external SDRAM banks Automatic support for self-refresh, auto- refresh and initialization of SDRAM 4-channel DMA controller In-system debug/breakpoint unit Power-down d and power-management modes CSL cells can be configured as memory, including true dual-port operation 26

27 Atmel FPSLIC FPSLIC: Field-Programmable System-Level Integrated Circuit Introduced in 1999, as Triscend E5, is equipped with Atmel s own 20 MIPS, 8-bit RISC processor. FPSLIC Secure (AT94S) chips integrate configuration memory in the programmable SoC device to provide more security. Software tool provides hw-sw cosimulation capability. 27

28 Cypress MicroSystems PSoC Eight 8-bit digital PSoC blocks 4 Digital Basic Type A blocks: Timer/Counter/Shifter/CRC/PRS/Deadband functions 4 Digital Communications blocks: Timer/Counter/Shifter/CRC/PRS/Deadband functions Full-duplex UARTs and SPI master or slave functions Twelve analog PSoC blocks 3 types: ContinuousTime (CT) blocks, and type 1 and type 2 Switch Capacitor (SC) blocks that support 14-bit Multi-Slope and 12 bit Delta- Sigma ADC, successive approximation ADCs up to 9 bits, DACs up to 9 bits, programmable gain stages, sample and hold circuits, programmable filters, differential comparators, and temperature sensor 28

29 Soft-core processor embedded on an Apex20K FPGA, taking 2% of FPGA logic capacity. Compiler : GNUPro C compiler, and Quartus is used to design and implement the hardware portion. Altera Excalibur Nios Family 29

30 Altera - Excalibur TM ARM-Based Family Industry-standard ARM922T 32-bit RISC processor core operating at up to 200 MHz Memory management unit (MMU) included Builds upon features of the APEX 20KE family, with up to 1,000,000 gates Harvard cache architecture with separate 8- Kbyte instruction and 8-Kbyte data caches Internal single-port and dual port SRAMs External SDRAM External flash memory Several on-chip peripherals including ETM9 embedded trace module, interrupt controller, UART, timer, and watchdog timer 30

31 Refer to lecture 4 Xilinx VirtexII PowerPC Based 31

32 SoC Platform Example: Bluetooth Bluetooth: used for low-power wireless personal area networks (WPANs). Overall architecture consists of an RF front-end, a baseband controller, and software to implement the Bluetooth protocol stack. Bluetooth architecture Bluetooth protocol stack 32

33 Bluetooth Protocol Enables users to make instant connections between a wide range of communication devices Complete wireless specification and link with normal modules up to 10 m or, up to 100 meters, with a power amplifier Supports up to seven simultaneous links Data rate of 1 Mega symbols per second Operates in the Industrial, Scientific, and Medical (ISM) frequency band of 2.4 GHz, ensuring worldwide communication compatibility Frequency-hopping radio link for fast and secure voice/data transmission Supports point-to-point, point-to-multipoint (including broadcast) connectivity Low power consumption 33

34 Baseband Processing Unit of Bluetooth WPAN is a suitable application for platform-based design: 1. Enormous hardware, software, design and verification flows, technology, and testing issues are prohibitive in the market windows associated with this type of product. 2. Bluetooth standard is upgraded or customer requirements shift, so design may become obsolete. 3. Other PAN standards under development with similar characteristics. Platform concept will be illustrated with design process of the baseband processing unit of Bluetooth. Software portion of the protocol stack runs on ARM7TDMI processor. Responsible for Bluetooth functions associated with establishing connections between devices, and interpreting the packets to determine the services requested by other devices. 34

35 Bluetooth Baseband Platform Slh Saleh et al., System-on-Chip: Reuse and Integration, Proceedings of the IEEE, June

36 Components of Bluetooth Baseband The ARM7 processor requires high-speed connections to certain blocks: shared memory controller (SMC), direct memory access (DMA) controller, test interface controller (TIC), and power and clock control units. Connections can be implemented using the synchronous advanced highspeed bus (AHB) of the AMBA bus standard. Bus requires development of a bus arbiter and decoder functions. Arbiter: Ensures that only one bus master initiates data transfers at a time Decoder: Performs decoding of the transfer addresses and selects slaves appropriately The other components in the system operate at different speeds and are connected using the asynchronous advanced peripheral bus (APB). Components include: watchdog and other timers, general-purpose input/output (GPIO) devices, programmable interrupt controller (PIC), UART, and USB interface standards. 36

37 Components of Bluetooth Baseband Baseband Controller (BBC) performs the DSP functions on the incoming and outgoing g bit streams and radio control functions, and is interfaced to the APB. Bus bridge is used to interface the AHB to the APB. Programmability in the platform: 1. ARM processor is programmable, 2. Local embedded FPGA to speed up critical sections of the code in protocol stack 3. Other interface blocks can be replaced by a similar embedded FPGA so long as the resulting fabric does not consume a large area or exceed the power specifications of Bluetooth 37