PAE2248 System-on-Chip Design

UIV : SoC Design Validation and Core

L3: SoC Design Validation

Presented By
Dr. V. Vaithianathan
Associate Professor, ECE Dept
 Lesson Plan
Sl. No. of
Lecture
No Hours

L1 Core-Level Validation 2

L2 Core Interface Verification 1

L3 SoC Design Validation 2

L4 Microprocessor Cores 1

L5 Core Integration and On-Chip Bus 1

L6 Examples of SoC: Media Processors 1

L7 Examples of SoC: Set-Top Box SoC 1

 Lecture 3
• SoC Design Validation
 Session Objectives
• To understand various steps involved in SoC
Design Validation
 Session Outcomes
• At the end of this lecture, the students will
be able to know about
– SoC Design Validation
 SoC Design Validation
• SoC-level design validation requires a real application
run of sufficient length.
• Thus, fully functional models of all cores and
interfaces are needed.
• This simulation cannot be done at logic level or even
at RTL level because the present-day logic- and RTL-
level simulation tools are too slow.
• For example, the simple booting-up of a real-time
operating system (RTOS) at RTL level can take more
than 24 hours.
• Thus, higher levels of abstractions are used that
include the ISA model, bus functional model (BFM),
and C/C++ models.
 SoC Design Validation
• At SoC-level validation, RTL models are used for the
functional cores, behavioural and ISA models for
memory and processor cores, and bus functional
models and bus monitors for interface and
communications blocks.
• Most of the time, errors are detected manually using
a bus monitor or by the sequence monitor on the
communications interfaces.
• Figure 4.5 illustrates the approximate relative speed
of simulation at different levels of abstraction.
• In Figure 4.5, simulation speeds are illustrated
relative to simulation speeds at the logic level, which
is generally slower than 10 cycles per second at logic
level. The simulation speed at RTL level is generally
about 100 cycles per second.
 SoC Design Validation

Figure 4.5 Approximate comparison of simulation speed at various

abstraction levels.
 SoC Design Validation
• The simulation speed can be improved using cycle-
accurate models.
• In cycle-accurate models, all implementation detail is
removed, but enough timing information is kept so
that all transactions are accurate at clock boundaries.
• BFM and ISA models further provide one order of
magnitude improvement in simulation speed. Using
higher level models in C/C++, the simulation can be
sped-up to two to three orders of magnitude over the
simulation speed at RTL level.
• More than 10,000 cycles per second, hardware
software cosimulation, can be done and small
fragments of real application code can be used for
design validation.
 Cosimulation

Figure 4.6 SoC cosimulation validation flow

 Cosimulation
• System specs for cosimulation flow are shown in
Figure 4.6.
• In cosimulation, hardware can be modelled in C/C++
and the entire system can be executed like a single
C/C++ program.
• However, it would not be system verification at the
implementation level; rather it is a behavioural
verification.
• HDL/RTL description is required for verification
because it represents the implementation of hardware
components.
• Cosimulation requires one or more HDL simulators
and a C/C++ platform (compiler, loader, linker, and
other pieces from the computer operating system).
 Cosimulation
• In cosimulation, two or more simulators including
HDL simulators and software simulators are linked.
• Hence, the communication between different
simulators is a key item.
• The simplest communication structure for a multi-
simulator environment is the master/slave behaviour.
• In master/slave operation, the HDL simulator acts as
the master and the software simulator behaves as the
slave.
• Slave simulators are invoked using techniques similar
to procedure calls and can be implemented by either
calling an external procedure from the master
simulator or by encapsulating the slave simulator
within a procedure call.
 Cosimulation
• Most HDL simulators provide a rich set of external
procedure calls for invoking C functions.
• For example, Verilog provides PLI/VPI functions that
can be used to enclose C code.
• VHDL supports foreign attributes within an associated
architecture block.
• This feature allows part of the VHDL code to be
written in C.
• These procedural calls impose some restrictions on
the execution of slave simulators, such as requiring
that slave simulator functions be executed within a
single invocation.
• The C program has to be made into a set of C
function calls seemingly independent of each other.
 Cosimulation
• This scheme becomes too complex to use when there
are multiple interaction points with the rest of the
hardware model.
• Also, it is almost impossible to achieve concurrency
using individual C function calls because the
master/slave combination still provides a single
execution process.
• The distributed cosimulation model overcomes these
restrictions.
• Distributed cosimulation is based on a communication
network protocol that is used as a software bus.
• Both master/slave and distributed cosimulation
models are shown in Figure 4.7.
 Cosimulation

Figure 4.7 Cosimulation models: (a) master/slave model and (b)

distributed simulation model.
 Cosimulation
• In distributed cosimulation, each simulator
communicates with the cosimulation bus through
prespecified procedure calls.
• The implementation of the cosimulation bus may be
based on standard system facilities such as Unix IPC
(interprocess communications) or Sockets.
• It can also be implemented as an ad hoc simulation
backplane.
• In this structure, the HDL simulator and the C
program run concurrently as independent software
programs (HDL simulators are also C programs).
• Cosimulation models (C program and the HDL
processes) should be independent of the
communication mechanism used.
 Cosimulation
• There are two advantages to this method:
• Modularity is achieved because various modules
can be designed using different HDL languages.
• Flexibility is achieved because an HDL model can
be replaced by a model at a higher level of
abstraction for increased speed, or with a model at
a lower level of abstraction for more details as the
design progresses.
• Figure 4.8 illustrates how debugging can be done in a
cosimulation environment. It also shows the flow for
generating the executable code.
• Figure 4.8 essentially provides a more detailed view
of Figure 4.7 in that it shows the operating system
calls of primitive functions in software modules.
 Cosimulation

Figure 4.8 Cosimulation debugging model.

 Cosimulation
• These calls are a set of C functions available in a
library, which allows the controlling, sending, and
receiving of data from a Unix/IPC channel.
• By calling these functions, the C program (software
application) can communicate with the IPC channel.
• The software part is run as a separate process in the
host computer operating system, while the executable
code is wrapped inside the C debugger.
• Similarly, when the C program interacts with a set of
hardware modules (by accessing I/O ports of
VHDL/Verilog entities), it calls OS primitives to
interact with the Unix/IPC channel.
 Cosimulation
• On the hardware side, HDL executable is run by the
HDL debugging tool (the HDL simulator can also be
executed without the debugger but executing it
through the debugging tool is much more useful in
cosimulation) and interacts with the IPC channel via
the HDL I/O ports.
• The IPC channel is accessed by the HDL entities
through the OS primitive calls, which are C functions
wrapped inside the HDL entities to access the IPC
channel. In VHDL, C functions can be invoked by
foreign attributes and in Verilog by PLI.
• These OS primitive procedures perform the tasks of
C-HDL data type conversion, synchronization, and
propagation of events between the HDL simulator and
the IPC channel.
 Emulation
• As illustrated in Figure 4.5, the cosimulation speed at
the C/C++ level is about 10,000 cycles per seconds.
• This speed is barely enough to simulate a small
fragment of an application.
• To simulate any reasonable length of real-time
application, simulation speeds on the order of a
million cycles per second are needed.
• Furthermore, cosimulation does not verify
implementation.
• It essentially validates the behavioral specs of the
system.
• These problems are overcome by emulation.
 Emulation
• Although emulation is still 1 to 2 orders of magnitude
slower than the actual silicon, more than 1 million
clocks per second can be simulated and, thus, decent
size application segments can be run.
• One major advantage of emulation is that ‘what if’
scenarios of design can be examined and bugs can be
fixed.
• Current emulation technology uses synthesized RTL.
• Hence, it can be viewed as a method for checking
functional correctness at the implementation level.
• Because of the different speed in emulation and
actual silicon, emulation is not very useful in
detecting timing errors.
 Emulation
• Other disadvantages of emulation are compilation
time after every change and different design flow
from the actual silicon implementation flow.
• In general, emulation technology provides
programmable interconnect, fixed-board designs,
relatively large gate counts, and special memory and
processor support.
• Emulation can give fast performance if the entire
design can be loaded into the emulation engine itself.
• Performance degrades if a significant portion of the
chip or the testbench is loaded onto the host
computer.
 Emulation
• Present-day emulation systems can be broadly
divided into two categories: (1) FPGA-based systems
and (2) custom systems.
• In FPGA-based systems, the whole design netlist is
partitioned and mapped onto off-the-shelf FPGAs.
• Examples of this category are Quickturn’s Animator, System
Realizer, Mentor Graphics SimExpress, Zy’cad’s Paradigm RP
and XP, Apix’s System Explorer, and Pro Explorer.
• Custom system emulators are based on a unique
architecture with numerous special-purpose
processors to emulate logic.
• In these systems, a compiler maps each logic gate
onto a special-purpose processor.
• Examples are Quickturn’s Cobalt and Synopsys Arkos.
 Hardware Prototypes
• Despite the best attempts by engineers to make the
first silicon fully functional, only about 80% of designs
work correctly when tested at the wafer level, and
more than half fail when put into the system for the
first time.
• The primary reason is the lack of system-level testing
with a sufficient amount ofreal application runs.
• The only means to do it with present-day technology
is by using either FPGA/LPGA or ASIC silicon
prototypes.
• When the design is too large, building a silicon
prototype and debugging it in the final system is the
best method and is more cost- and time efficient than
the extended verification and cosimulation methods.
 Hardware Prototypes
• With a silicon prototype, the same silicon can be used
for the first several bugs without a new silicon run.
• However, deciding when to use silicon is an important
decision because producing a silicon prototype is a
costly proposition.
• These factors should be considered:
1. The diminishing bug rate in verification and
cosimulation.
• When the basic bugs have been eliminated, an
extensive application run will be required to
find other bugs.
• Cosimulation and emulation may not be able to
run an application for extensive time periods.
 Hardware Prototypes
• These factors should be considered:
2. The difficulty of finding bugs.
• If finding a bug takes a few orders of
magnitude more time than the time required to
fix it, then a silicon prototype is very useful
because it finds bugs quickly.
3. The cost (manual effort, time-to-market) of
finding bugs.
• If the search for bugs with the cosimulation or
emulation methods is extremely costly, then
silicon prototyping should be considered.
•
 Hardware Prototypes
• For smaller designs, FPGA/LPGA (field programmable
gate-array/laser programmable gate-array)
prototypes are adequate.
• LPGAs allow reprogrammability so the bug fixes can
be retested, whereas FPGAs offer higher speeds and
higher gate counts than LPGAs.
• Both FPGA and LPGA lack the gate count capacity and
speeds of ASICs, so they are good for smaller blocks
or cores, but not suitable for the entire SoC.
• Several FPGAs can be used to build a prototype of the
entire SoC.
• If a bug fix requires the chip to be repartitioned,
interconnects between FPGAs will require change, and
hence modifications can be complex.
 Hardware Prototypes
• A partial solution to this problem is to add custom
programmable routing chips to interconnect FPGAs.
• With programmable routing chips, if the interconnects
change, routing can be done under software control.
• In a prototype flow, after studying the system’s
behaviour, simulated HDL and/or a C program
description is used in cosynthesis.
• Similar to cosimulation, cosynthesis refers to the
simultaneous development of the hardware and
software.
• The purpose of cosynthesis is to produce C code and
hardware that will execute on a real architecture.
 Hardware Prototypes
• In general, this step consists of mapping the system
onto a hardware-software platform that includes a
processor to execute the software and a set of ASICs
to realize the hardware.
• The final prototype is generated by using the C code
of the software parts and by using logic synthesis,
placement, and routing to create the hardware
components.
• Synthesis tools translate the HDL descriptions/models
into gate-level netlists that are mapped to FPGAs or
ASICs as prototypes.
 Review Questions
1. What is SoC design verification?
2. What do you mean by design validation?
3. Why is verification important in the SoC design
flow?
4. What is difference between IP and SoC
verification?
5. Explain in detail SoC Design Validation.
6. Explain in detail the process of Cosimulation.
7. What is meant by Emulation?
8. What are Hardware Prototypes?
 Session Summary
• In this lecture, we have discussed about
– SoC Design Validation
 Text Books & References
1. Rochit Rajsuman, “System-on-a-chip: Design and
Test”, Advantest America R & D Centre, 2000.
2. Hubert Kaeslin, “Digital Integrated Circuit Design: From
VLSI Architectures to CMOS Fabrication”, Cambridge
University Press, 2008.
3. B. Al Hashimi, “System on chip-Next generation
electronics”, The IET, 2006.
4. P Mishra and N Dutt, “Processor Description Languages”,
Morgan Kaufmann, 2008.
5. Michael J. Flynn and Wayne Luk, “Computer System
Design: System-on-Chip”, Wiley, 2011.
Thank You