1 Process - 2.1 Canonical SoC Design - 2.2 System design flow - 2.3 The Specification Problem - 2.4 System design process
Transcript
Slide 1
1 Chapter 2. The System-on-a-Chip Design Process - 2.1
Canonical SoC Design - 2.2 System design flow - 2.3 The
Specification Problem - 2.4 System design process
Slide 2
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
Slide 3
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
Slide 4
4 Figure 2-1 Canonical hardware view of SoC
Slide 5
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
Slide 6
6 2.21 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
Slide 7
7 2.2 System Design Flow Figure 2-2: Traditional waterfall ASIC
design flow
Slide 8
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
Slide 9
9 2.2.2 Top-Down vs. Bottom-Up
Slide 10
10 2.2.2 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)
Slide 11
11 2.2.3 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
Slide 12
12 2.3 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.
Slide 13
13 2.3.1 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
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.
Slide 16
16 Figure 2-4 Top-level system design and recommended
applications for each step
Slide 17
17 2.4 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.
Slide 18
18 2.4 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
Slide 19
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
Slide 20
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
Slide 21
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
Slide 22
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
Slide 23
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
Slide 24
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