Scribd
Upload
18 views18 pages

Uiv L2

Uploaded by

Benzer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views18 pages

Uiv L2

Uploaded by

Benzer
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 18

PAE2248 System-on-Chip Design

UIV : SoC Design Validation and Core

L2: Core Interface Verification

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 2
• Core Interface Verification
Session Objectives
• To understand various steps in involved Core
Interface Verification
Session Outcomes
• At the end of this lecture, the students will
be able to know about
– Core Interface Verification
Core Interface Verification
• In many present SoC designs, on-chip addressing and
data buses provide interface and connectivity among
the cores.
• These buses operate by a controller under preset
rules such as polling and request/grant protocols.
• Thus, it is necessary to validate the controller’s
operation as well as the protocol behaviour.
• The controller itself could be considered to be a core.
• Hence, the validation methodology described already
in previous lecture is applicable for the bus controller.
• The key difference in interface validation and core
validation is the protocol behaviour for data transfer
across the core boundary.
• For this purpose, a limited number of transactions are
simulated with various data and control values.
Protocol Verification
• To verify the protocol behaviour, it is necessary that
all transaction types that may take place are clearly
defined.
• Creating a list of all transactions types and developing
at least one test for each transaction type is strongly
advised.
• In most SoC designs, not all possible transaction
types (supported by the protocol) are allowed.
• Transaction types are generally restricted to a small
number.
• Thus, identifying all supported transaction types and
developing test cases for them is not an
overwhelming task.
Protocol Verification
• To further automate the testing of protocol behaviour
using multiple sets of data in any transaction, simple
and regular structures such as bus monitors can be
used with on-chip buses.
• By building bus monitors within the bus controller,
both observability and controllability can be enhanced
for the verification of transaction protocols.
• Built-in bus monitors allow control and observation of
precise transactions in proper order and are also
useful in the debugging process.
• However, note that the bus functional models are
necessary instead of a fully functional model when
bus monitors are built within the bus controller.
Protocol Verification
• In the modular design, the behavioural and RTL
description of an interface block can be identified
separately from the core’s internal logic.
• This separation allows easy monitoring of the
interaction among the interface blocks using bus
monitors and simulation blocks using bus monitors
and simulation at behavioural as well as RTL levels.
• This concept is illustrated in Figure 4.4.
• In this method, the bus functional model of every
core except the core-under-test replaces the physical
netlist of each core.
Protocol Verification
• For each interface block, an RTL testbench is created
that generates the test sequence using the bus
functional models of various cores and a behavioural
or RTL model of the core-under-test.
• The deterministic test data (stimulus) for this
testbench should be based on the user’s expectations
of transaction data.

Figure 4.4 Illustration of the use of a bus functional model and bus
monitors to verify core interface.
Protocol Verification
• This approach allows the simulation of interfaces and
transaction protocols on global buses as well as in
point-to-point interfaces when data from one core to
another is transferred directly and not through a
global bus.
• One limitation of this method is that it does not
ensure correct behavior for all possible data values
and for all sequences that each interface would
receive.
• Hence, random data should also be used as part of
the stimulus.
• Use of random data requires special consideration so
that core logic is not forced into an illegal state and
so that illegal data sequences do not occur at the
core’s inputs.
Protocol Verification
• Thus, either during the random data generation a
filter should be used or a checker should be built with
the interface that can suppress illegal data.
• The response checking is done manually because it is
difficult to characterize expected values even when
deterministic data are used for testing.
• Therefore, automatic checking is limited to only
generic results such as checking for illegal output
transactions and state machine loops.
Gate-Level Simulation

Figure 4.3 Core-level timing validation flow.


Gate-Level Simulation
• The gate-level netlist of bus interface logic should be
verified for both functionality and timing.
• Formal verification can be used to verify the
correctness of the gate level netlist.
• The timing verification flow such as that shown in
Figure 4.3 should be used, followed by the gate-level
simulation using back-annotated delays in the
Verilog/VHDL netlist.
• Generally, the number of gates in the bus interface
logic is small and, hence, gate-level simulation can be
accomplished efficiently
Review Questions
1. What is SoC verification?
2. What does SoC verification engineer do?
3. What is the target of verification in SoC
verification?
4. What are the challenges of SoC verification?
5. Discuss in detail Core Interface Verification
6. Discuss in detail Protocol Verification.
7. Illustrate the use of a bus functional model and
bus monitors to verify core interface.
8. What is Gate-Level Simulation?
Session Summary
• In this lecture, we have discussed about
– Core Interface Verification
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

You might also like