1 Chapter 2. The System-on-a-Chip Design Process Canonical SoC Design System design flow The Specification Problem System design process

2 2.1 A Canonical SoC Design Canonical or generic form of an SoC design(Fig. 2-1) – A microprocessor and its memory subsystem - On-chip buses to provide the datapath bet. cores - A memory controller for external memory - A video decoder - A timer and interrupt controller - A general purpose I/O (GPIO) interface - A UART interface

3 It contains most of the structures and challeges found in real SoC designs. For example: – Microprocessor could be anything from an 8-bit 8051 to a 64-bit RISC - Memory could be single or multi-level, and could include SRAM and/or DRAM - I/O controller could include PCI, Ethernet, USB, IEEE 1394, A/D, D/A converters - The vieo decoder could be MPEG, ASF, or AVI - The GPIO could be used for powering LEDs or sampling data lines - The external momory could be DRAM, SRAM, or Flash

4 Figure 2-1 Canonical hardware view of SoC

5 2.2 System Design Flow To meet the challenges of SoC, chip designers are changing their design flows in two major ways: – From a waterfall model to a spiral model - From a top-down methodology to a combination of top- down and bottom-up

Waterfall vs. Spiral Waterfall model – Process start with the development of a specification for the ASIC - Algorithm may be developed by a graphic expert - Design team develops the RTL for the ASIC - Synthesis experts synthesizes the ASIC into a gate-level netlist, then timing verification is performed - Once design meets its timing goals, the netlist is given to the physical design team for placement and routing - A prototype chip is built and tested - This prototype chip is delivered to the software team

7 2.2 System Design Flow Figure 2-2: Traditional waterfall ASIC design flow

8 Spiral development model The spiral SoC design flow is characterized by: - Parallel, concurrent development of hardware and software - Parallel verification and synthesis of Modules - Floorplanning and place-and-route included in the synthesis process - Module developed only if a predesigned hard or soft macro is not available - Planned iteration throughout

Top-Down vs. Bottom-Up

Top-Down vs. Bottom-Up Top-Down design process – Write complete specifications for the system or subsystem - Refine its architecture and algorithms - Decompose the architecture into well-defined macros - Design or select macros - Integrate macros into the top level - Deliver the subsytem/system to the next higher level of integration - Verify all aspects of the design(functionality, timing)

Construct by Correction Sun Microsystems’ success of UltraSPARC Develop- ment by methodology called “Construct by Correction” – Team made the first pass through the design cycle – from architecture to layout- as fast as possible - By development plan that allowed a single group of engineers to take the design through multiple complete iteration, the team was able to see their mistake, correct them, and refine the design several times before the chip was finally fabricated. - It is not possible at the architetural phase of the design to foresee all the implication of their decisions would have on the final physical design

The Specification Problem The first part of the design process consists of recursively developing, verifying, and refining a set of specifications until they are detailed enough to allow RTL coding to begin. If you know what you want to build, implementation mistakes are quickly spotted and fixed. The cost of documenting a specification during the early phases of a design is much less that the cost of documenting it after the design is completed. Specifications are largely descriptions of interfaces.

The Specification Problem Hardware specification requirements – Functionality - Timing - Performance - External interface to other hardware - Interface to SW(register definitions) - Physical design issues such as area and power

14 Software specification requirements – Functionality - Timing - Performance - Interface to HW - SW structure, kernel

15 Types of Specifications – Formal specification: Formal specification languages typically provide a mechanism for describing not only functional behavior, but timing, power, and area requirements - Executable specifications: An executable specification is typically an abstract model for the hardware and/or software being specified, written in C, C++, SDL. At the lower level, hardware is usually descrived in Verilog or VHDL.

16 Figure 2-4 Top-level system design and recommended applications for each step

The System Design Process System design involve a large number of complex decisions and tradeoffs, such as: – What goes in software or in hardware - What processor(s) to use, and how many - What bus architecture is required to achieve the required system performance - What memory architecture to use to reach an appropriate balance between power, area and performance.

The System Design Process 1. Create the system specification – The process begins by identifying the system reuirements: the required functions, performance, cost, and development time - Then, a high-level algorithmic model for the overall system is developed in C/C++ - Tools such as COSSAP, SPW, and Matlab may be useful for some algorithm - The high-level model provides an executable specification for the key functions of the system

19 2. Develop a behavioral model - Develop a high-level behavioral model for the overall system to test the basic algorithms of the system design and to show that they meet the requirements outlined in the specification. - The model provides an executable specification for the key fuctions of the system - It can be used as the reference for future versions of the design

20 3. Refine and test the behavioral model - Verification environment for the high-level model is developed to refine and test the algorithm - This environment provides a mechanism for refining the high-level design, and verifying the functionality and performance of the algorithm - It can be used later to verify models for the hardware and software, such as an RTL model verified using hardware/software cosimulation - For system with very high algorithm content, considerable model development, testing, and refinement occurs before the hardware/software partitioning

21 4. Determine the hardware/software partition – As the high-level model is refined, the system architects determine the hardware/software partition; that is division of system functionality between hardware and software - Manual process requiring judgment and experience on the part of the system architects and a good understanding of the cost/performance trade-offs for various architectures - A rich library of preverified, characterized macros and a rich library of reusable software modules are essential for identifying the size and performance of various hardware and software functions

22 5. Develop a hardware architectural model – Specify and determine a detailed hardware architecure - Determine which hardware blocks will be used and how they will communicate - Memory architecture, bus structure, and bus bandwidth can be critical issues - Use transaction-level models like SystemsC to model interfaces and bus behavior to avoid significant running time of application code in RTL

23 6. Refine and test the architectural model (cosimulation) – Software development after the hardware has been built often lead to delayed or cancelled projects. - Architectural model for the system can be used for HW/SW cosimulation providing sufficient accuracy that SW can be developed and debugged on it. - As SW content of systems continues to grow, HW/SW codevelopment and cosimulation will become increasingly critical to the success of SoC projects

24 7. Specify implementation blocks – Hardware specification: a detailed spec. of the functionality, performance, and interfaces for the HW system and its component blocks. - HW spec. includes a description of the basic functions, the timing, area, power requirements, and physical and SW interfaces, with detailed descriptions of I/O pins and the register map. - Architectural model itself functions as an executable specification for the hardware