DESIGN OF AUTOMATION FRAMEWORK FOR
SILICON VALIDATION
A PROJECT REPORT
By
TANISHA SHARMA (Reg. No:RA201200801001)
Under the guidance of
Dr. K. SUGANTHI
(Assistant Professor, Department of Electronics and Communication Engineering)
Submitted in partial fulfillment for the award of the degree of
MASTER OF TECHNOLOGY
in
VLSI DESIGN
DEPARTMENT OF ELECTRONICS AND COMMUNICATION
ENGINEERING
OF
COLLEGE OF ENGINEERING AND TECHNOLOGY
SRM Nagar, Kattankulathur- 603203, Chengalpattu District
JUNE 2022
BONAFIDE CERTIFICATE
This is to certify that this report, of the project work named DESIGN OF
AUTOMATION FRAMEWORK FOR SILICON VALIDATION submitted in
partial fulfillment of the requirement for the award of degree, M.Tech in VLSI
Design, by TANISHA SHARMA, Reg.No.RA2012008010001, is the bonafide
project work of the student, who carried out under my supervision. Certified further
that, to the best of my knowledge further that, to the best of my knowledge the work
herein has not been submitted for the award of this or any other degree, on an
earlier occasion on this or any other candidate.
Signature of the Guide
Dr. K. SUGANTHI
Assistant Professor
Department of Electronics and
Communication Engineering
SRM Institute of Science and
Technology
Kattankulathur- 603203
Signature of Head of
Department
Dr. SHANTHI PRINCE
Professor
Department of Electronics and
Communication Engineering
SRM Institute of Science and
Technology
Kattankulathur- 603203
This project report is submitted for the project university examination held on June,
2022, at Department of ECE, SRMIST, Kattankulathur
External Examiner
Internal Examiner
ACKNOWLEDGEMENT
I wish to express my deep sense of gratitude and sincere thanks to our Professor
and Head of the Department Dr. Shanthi Prince, for her constant
encouragement, timely help and advice offered to me.
I would also like to acknowledge with much appreciation to the crucial role of
my guide, Dr. K. Suganthi, Assistant Professor, ECE Dept, as well as the panels
especially in our project presentation that has improved my presentation skills by
their comments and tips. I would also like to extend my gratitude to Karthikeyan
K, Senior Manager Test Engineer, Infineon Technologies for his guidance in the
mechanics of the project
I would like to express my sincere thanks to our PG Project coordinator, Dr. J.
Selvakumar,
Professor, ECE Dept., for his constant help in shaping up the
project schedule and improving my time management skills.
I extend my gratitude and heartfelt thanks to all the teaching and non-teaching
staff of the Electronics and Communications Department and to my parents and
friends, who extended their kind cooperation by means of valuable suggestions
and timely help during the course of this project work.
I would like to express my sincere thanks to my external guide Guruprasad
Kamath, Senior Staff Engineer, and Antony Varghese, Senior Staff Engineer,
Infineon Technologies, for his guidance and support during the time I worked on
the project and helped me grow in the competing environment.
TANISHA SHARMA
RA2012008010001
DECLARATION
I hereby declare the Project Work-phase-2 entitled “DESIGN OF
AUTOMATION FRAMEWORK FOR SILICON VALIDATION” to be
submitted for the Degree in Master of Technology is my original work as individual
and the dissertation has not formed the basis for award of any Degree, Diploma,
Associateship or Fellowship of similar other titles. It has not been submitted to any
other University/Institution for the award of any Degree/Diploma.
Place: Chennai
Tanisha Sharma
Date:
RA2012008010001
List of Contents
Title
Page Number
Abstract
1
Chapter-1
Introduction to Validation
1.1 Literature Survey
1.2 Motivation
1.3 Problem Statement
1.4 Objectives
1.5 Methodology of the Project
2
Chapter-2
Validation
2.1 Introduction to Validation Set-up
2.2 Validation Hardware Details
2.3 Peripheral Systems in Silicon
2.4 Validation tests for Silicon Peripherals
9
Chapter-3
Communication Blocks
3.1 Protocols in Validation
3.2 Automating the protocols
18
Chapter-4
Automation Framework Architecture
3.1 Introduction to Automation framework
3.2 Comparison with Existing Framework
20
Chapter-5
Results
26
Chapter-6
Conclusion and Future Scope
6.1 Conclusion
6.2 Future Scope
30
Bibliography
31
List Of Figures
Title
Page Numbers
Figure-1.1
Silicon Validation steps
4
Figure-1.2
Methodology of the Project
7
Figure-2.1
Complex switch matrix validation set-up.
9
Figure-2.2
Wi-Fi BT Pioneer Kit
11
Figure-2.3
Overview of blocks in PSoC
12
Figure-2.4
System Peripherals in Silicon
14
Figure-3.1
DUT and dutcomm interface
18
Figure-3.2
Protocol validation set-up
19
Figure-4.1
Automation framework
21
Figure-4.2
Miniprog-4
21
Figure-4.3
Dutcomm board
22
Figure-4.4
PSoC 6 IC
22
Figure-4.5
PSoC-5 LP
22
Figure-4.6
Wi-Fi BT Pioneer Kit
23
Figure-4.7
Pre-silicon FPGA set-up
23
Figure-4.8
Validation board set-up after fabrication
23
Figure-4.9
VRD
24
Figure-4.10
Test set-up selection
24
Figure-5.1
I2C waveforms for DUT operating at 3.3V
26
Figure-5.2
I2C waveforms for DUT operating at 2.4V
26
Figure-5.3
I2C waveforms for DUT operating at 1.8V
27
Figure-5.4
SWD waveforms for DUT operating at 3.3V
27
Figure-5.5
SWD waveforms for DUT operating at 2.4V
27
Figure-5.6
SWD waveforms for DUT operating at 1.8V
28
Figure-5.7
Logs for Automation framework test run
28
Figure-5.8
Home Page screen of automation GUI
29
List of Tables
Title
Page Numbers
Table 2.1 Summary of PSoC variants
12
Table 3.1 Protocol Comparison
18
Table 4.1 Framework Comparison
24
Abstract
Ensuring correct operation despite rising levels of design complexity has been a
major focus of research and development since the dawn of digital system
design. These efforts led to remarkable advances in the theory and practice of
design verification and manufacturing testing of digital systems over several
decades. Silicon validation of overwhelmingly complex systems of the future is
an emerging field of research with exciting opportunities for major innovations.
Pre-Silicon validation allows for earlier identification of bugs further upstream,
reduces development times and enables more developers to access the latest
simulated silicon. Post-silicon validation involves operating one or more
manufactured chips in actual application environments to validate correct
behaviors over specified operating conditions. The objective is to ensure that no
bugs escape to the fabrication or customers.
1
CHAPTER 1
INTRODUCTION TO VALIDATION
When you call the validate method, it runs validate function on every textfield of
your form. If any of the text fields contains errors, the validate method reconstructs
the form to display any error messages, and returns false. If the users input is
invalid, the validate function returns a string that contains the error message. If the
field is actually present in your database, then accept parameter should be set or
included with True, otherwise, this validator will not be executed.
The field that is being validated will be excluded from the query data returned by
validate methods if the otherField field is equal to value. Otherwise, the validate
and validated methods of a validator will return all of the data that has been
verified, including the array and all its keys, even though these keys are unchecked
by the validation rules for the other nested arrays. If you do not wish to use
validate methods in your requests, you can manually construct the Validator
instance using the Validator Facade. After you have verified incoming request data
using the Form Request or manually created validator instance, you might wish to
extract incoming request data that has actually been verified.
When using a validate method on an XHR request, Laravel does not create a
redirection response. If needed, you can supply custom error messages for a
validator instance to use in place of the default error messages provided by
Laravel. You can configure error messages used for the given combinations of
attributes and rules in the Validation Language file for the app. After you have
determined that a request has failed verification, you can flash an error message in
your session using the withError method.
To perform the validation, you should take action for at least three out of the
maximum of 24 messages, one for each named user that you specified, over the
course of 72 hours. Even if all messages are sent to the same email address, you
need to act on a message for each domain or subdomain in order to validate and
create a certificate.
If you are not receiving every validation email, or if your token has expired, you
can ask to have an email sent again. Because the validation emails required in the
authorization process may get blocked by spam filters or lost in transit, tokens
2
automatically expire in 72 hours. Under Domains, select Re-send Validation
Emails, choose each of the domains that need verification, then choose Re-send.
You can pass more than one character to each method in a class, and their
respective validations will run in the same order they were registered. You would
build one using the block, and each attribute passed to validates_each will be
checked against it. If you want to make sure the associated object itself is present
and valid, you should also use validates_associated. This also makes sure you
cannot forget to validate anything and unintentionally allow invalid data into your
database.
Since data validation may involve tool tips that tell a person which kind of data to
input, this is typically different for every field on your spreadsheet. To estimate
validation rules for your data set, you can use either the Evaluate Rules tool or the
Error Inspector. Validation rules can be created by clicking on the Validation Rule
button under the Add Rule group in the Attribute Rules view. The Ready-to-Use
Rules button provides access to a configurable validations gallery, which supports
creating constraints and validation rules.
You can declaratively specify validation rules in a single location (in a Model
class), and rules are enforced throughout your application. The controllers and
views that you created earlier in this tutorial will automatically receive the
validation rules you specified using the validation attributes on properties in the
Movie model class. When you need to modify validation logic, you can do it
exactly in one place by adding validation attributes on a model (in this example,
the Movie model).
You will not need to worry about disparate parts of your app being inconsistent in
the way rules are enforced, because all the validation logic will be defined in one
place and used everywhere. Active Record offers many default validation helpers
you can use right within the definition of the class.
When multiple conditions dictate if a validation should occur, you may use Array.
By using either of these validations, you ensure that a value is not null, which in
most cases will lead to a NULL value. This means under any other conditions,
checksum validation will fail and the package will drop, protecting your app
against data corruption.
You can set breakpoints on the create[httppost] method and check the method is
never called, the client-side validation will not send form data if it detects a
validation failure. If you disable JavaScript on the browser, then client validation is
disabled, you can check if ModelState.IsValid of the HTTP POST Create method
detects any validation errors. After Active Record has performed validation, you
3
can access any errors found via the errors instance method, which returns the error
collection.
If you are using the Rails Forms Helper to create your forms, when a validation
error occurs in a field, it will create an additional div> around the record.
A typical silicon validation step is as shown in figure 1.1.
Figure-1.1 Silicon Validation steps
For our Star Wars example, file starwars validation-test.t contains a set of queries
demonstrating different invalidities, and is a test file you can run to test out your
validator implementation reference. The validator procedures utilize the standard
procedures and methodologies documented in the Intel memory validation
procedures. Regulated manufacturing companies also employ SAP solutions for
production processes, facility maintenance, and asset management, and must
therefore maintain the status of the validations on assets, including tools,
equipment, and computing systems, at all times, including in production and in
maintenance phases. When combined with other technologies, customer-side
validation can be a cost-effective way of providing users immediate feedback
while using your website.
1.1 Literature Survey
Title
Authors
Journal
Inference
Post-Silicon
Validation
and
Diagnosis
Kanad
Bhasu,
Subhadip
Kundu
29th International
Conference on
VLSI Design and
2016 15th
International
Conference on
In this paper, the
post-silicon validation part
focuses on signal
selection, trace debug,
trace compression,test
generation; while the
4
Embedded
Systems (VLSID)
diagnosis deals with both
logic and chain diagnosis.
It also focuses on
diagnosis techniques with
test-response
compressors, which is
widely used in recent
industrial design.
Pre silicon
validation
methodology
breakthrough
for 3D IC
Wai Loon,
Hock Thien,
Bian Sim
INTERNATIONAL
TEST
CONFERENCE,
2018
The increase demand for
functionality and
miniaturization forces
industry to enhance chip
performance, without
sacrificing valuable board
space. This is achieved by
stacking silicon wafers and
interconnecting them
vertically known as a
three-dimensional
integrated circuit (3D IC) or
stacked die. This paper
explains the pre silicon
validation methodologies
implemented in
our facility today to
achieve effective testability
and debug capability of the
stacked device.
Automating
post-silicon
debugging
and repair
Kai-Hui
Chang, Igor
L. Markov ,
Valeria
Bertacco
IEEE/ACM
International
Conference on
Computer-Aided
Design, Digest of
Technical Papers,
2007
Paper proposes a
post-silicon debugging
methodology (FogClear)
that can repair some
electrical errors while
preserving functional
correctness. Thus,
automates the traditional
manual debugging process
and promises to reduce
engineers' debugging
effort.
Post-Silicon
Validation
Opportunitie
s,
Challenges
and Recent
Advances
Subhasish
Mitra, Sanjit
A. Seshia,
Nicola
Nicolici
Verification, B8.1
Reliability, Testing
and Fault
Tolerance, B 8.2
Performance
Analysis and
Design Aids, 2010
In this paper, an overview
of the post-silicon
Validation problem is given
and how it differs from
traditional pre-silicon
verification and
manufacturing testing.
Also major post-silicon
validation challenges and
recent advances have
been discussed.
5
Meta-model
Based
Automation
of Properties
for
Pre-Silicon
Verification
Keerthikum
ara
Devarajego
wda,
Wolfgang
Ecker
2018 IFIP/IEEE
International
Conference on
Very Large Scale
Integration
(VLSI-SoC)
In this paper, a
Pythonbased
generationlanguage and
framework for
hardwareproperties is
described in order
toincrease formal
verification productivity by
increase in HGLs inRTL
designs and makes the
approachplatform
independent.
1.2 Motivation
Design of ICs being held by customers are becoming complex and diverse as
technology advances. These ICs are used in multiple end products in today’s
market. Some examples are smartphones, computer and gaming products, Internet
of Things (IoT) devices. These devices are categorized as ‘multi-domain’, i.e.,
they contain digital, DC, analog and Radio Frequency (RF) circuitry all on the
same chip. Developing efficient validation programs for these multi-domain ICs
within a shorter Time to Market (TTM) is becoming a challenge. To overcome
this
challenge, most semiconductor companies use automation for validation,
which uses high speed communication protocol and
automated information
technology to rapidly perform tests that measure and evaluate a DUT.
The
architecture of an automation framework can be simple or complex and is chosen
based on the device under test. The validation process helps in defining the
defects or issues in the early stage of IC development so that those issues can be
removed in future fabrication of the IC. It also helps in stating on how much of
the customer requirements are being met by the first silicon revision fabricated
and the changes need to be made for further improvement. To improve the speed
of the validation process, industry automates the process.
1.3 Problem statement
Pre and Post silicon validation involves several test scripts to be run on a single
set-up at a given time. Running all these test scripts manually and with particular
configuration is hectic. Automating these test scripts will reduce so much work of
a validation engineer. But there is no defined framework for automating the test
scripts. Also, the result generation process is also manual and engineers have to
6
write documents manually after completing every project milestone, which is
again time consuming and not uniform. Several softwares are there today for
different tasks like programming firmware, I2C scanning, UART debug etc. This
spreaded software makes it very inefficient for the engineer to concentrate on
debugging as he/she is busy switching softwares and might also get confused
sometimes. No GUI exists today for the automation framework.
1.4 Objectives
1. To provide a well-defined and structured automation framework that could
run several test scripts smoothly over any set-up.
2. To provide users with a GUI that will contain the features from all different
softwares used today for different purposes, hence providing a one-stop solution
for Validation of silicon.
3. To reduce the work of engineer by defining a project tracking system called
Test Rail that would also generate the reports automatically at the completion of
each milestone.
4. To provide users with proper debug logs which will help engineers to resolve
the issue in less time as compared to what it takes today.
1.5 Methodology of the Project
Figure 1.2 Methodology of the Project
The design of the automation framework requires a clear understanding of how
validation works and its need. After understanding the need for validation, one
can move forward with designing the automation framework. The automation
framework for validation is designed in python as python has supporting libraries
for most of the bench instruments and one can easily generate algorithms for
protocols that are to be used during validation testing.
7
The silicon needs to be flashed with firmware for running automated test cases.
This firmware is written in C/C++ mostly using switch cases. When the dutcomm
board sends any communication packets to DUT, the DUT reads the packet and
performs the test according to one of the test cases.
During the run of each test case, some or the other IP is tested. To understand ad
write the code for IP test cases, learning the IP is another important step. Once
completed with writing of all the code, the code is now tested for its robustness
through regressing testing.
8
CHAPTER 2
VALIDATION
Validating a silicon requires a lot of hardware to be set-up. These hardware
includes:
1.
Boards-
a.
Silicon validation board (DUT)
b.
Pre-silicon validation set-up (FPGA)
c.
DUT communication board
2.
Bench Instruments
a.
Oscilloscope
b.
NI Chassis
c.
Source Measuring Unit
d.
Analog Function Generator
2.1 Introduction to Validation Set-up
The validation setup contains a main device under test connected to the
communication board, which is in turn connected to PC. To the PC and DUT,
connected are bench instruments that include Scope, SMUs, etc.
Figure-2.1 Complex switch matrix validation set-up.
9
The silicon of any high speed serial link PHY is required to be tested and
characterized for a number of internal blocks and interfaces, over PVT (process,
voltage and temperature) variations. To accomplish all these test scenarios, it
takes a huge amount of time to perform the same test repeatedly on PVT
variations, if done manually. Also the validation setup needs to be changed many
times while moving from one test case to another. For example in case of a high
speed USB transceiver tests, transmitter characterization needs the DUT (device
under test) to be connected to scope, while receiver tests are done with data
generator connected to the DUT. Similarly Voh, Vol level tests need a digital
multi-meter connected at serial interface whereas source meters are used in case
of driver current measurement. Also in all the tests some discrete components are
required to be connected at serial interface as per test requirement. During the
testing, test engineer has to switch across these connections manually as test cases
are executed.
2.2 Validation Hardware Details
Infineon offers a broad portfolio of low-power to high-performance microcontrollers
(MCUs) for various markets. They provide MCUs for the consumer, industrial and
automotive markets with our PSoC® MCU, Flexible MCU (FM) and Automotive MCU
Portfolios. They help solve problems for various market needs with their low-power,
flexible and high-performance MCUs. It covers all kinds of requirements, including
automotive (Devices that complement the portfolio with proven system software that has
been deployed in production vehicles around the globe.), industrial (Products that are at the
heart of the Industrial IoT) and consumer (Society interacts with electronic devices more
than ever for personalized productivity, entertainment and communication.).
→ Arm Cortex 32-bit MCUs
PSoC 6 bridges the gap between expensive, power hungry application processors and
low‑performance microcontrollers (MCUs). The ultra‑low‑power PSoC 6 MCU architecture
offers the processing performance needed by IoT devices, eliminating the trade-offs
between power and performance. The PSoC 6 MCU contains a dual‑core architecture, with
both cores on a single chip. It has an Arm® Cortex®‑M4 for high‑performance tasks, and an
Arm® Cortex®‑M0+ for low-power tasks, and with security built-in, your IoT system is
protected. PSoC 4 has tackled some of the complex portions of embedded system design
making it easier for you to get your product to market. Functions such as analog sensor
integration, capactitive touch, and wireless connectivity have been integrated and optimized
10
in PSoC 4to just work so you don’t have to.
Infienon's PSoC Analog Coprocessor simplifies the design of sensor-based systems by
delivering a scalable and reconfigurable architecture that integrates programmable analog
front ends (AFEs) and a signal processing engine (32-bit Arm® Cortex®-M0+) that can
calibrate and tune the AFE in software. The PSoC Analog Coprocessor enables designs to
send aggregated, pre-processed, and formatted sensor data over serial communication
interfaces to host processors.
→ PSoC 6 – Wifi BT Pioneer Kit
PSoC (programmable system-on-chip) is a family of microcontroller integrated circuits by
Cypress Semiconductor. These chips include a CPU core and mixed-signal arrays of
configurable integrated analog and digital peripherals.
Figure-2.2 Wi-Fi BT Pioneer Kit
Series of PSoC: There are five different families of devices, each based around a different
microcontroller core:
➔
➔
➔
➔
➔
PSoC 1 - CY8C2xxxx series — M8C core.
PSoC 3 - CY8C3xxxx series - 8051 core.
PSoC 4 - CY8C4xxxx series - ARM Cortex-M0 core.
PSoC 5/5LP - CY8C5xxxx series - ARM Cortex-M3 core.
PSoC 6 - CY8C6xxxx series - ARM Cortex-M4 core with an added ARM
Cortex-M0+ core (in some models).
11
Figure-2.3 Overview of blocks in PSoC
Table 2.1: Summary of PSoC variants
PSoC1
8-bit M8Ccore
PSoC3
PSoC4
PSoC5/5LP
PSoC 6
8-bit8051 core
(single-cycle)
32-bitARM
Cortex-M0
32-bitARM
Cortex-M3
up to67 MHz,
33MIPS
upto48 MHz, ?
MIPS
up to 80MHz,
84MIPS
Flash: 4KB to
32KB
Flash:8 KB to
64KB
Flash:16 KB to
256KB
Flash:32 KB to
256KB
Flash: 512 KB to
2048KB
SRAM: 256
bytesto 2KB
SRAM:3 KB to
8KB
SRAM:2 KB to
32KB
SRAM: 8KB to
64 KB
SRAM: 128 KB
to 512KB
up to 24MHz, 4
MIPS
32-bitARM
Cortex-M4 (up to
150 MHz)
32-bit ARM
Cortex-M0+ (opt.
up to 100 MHz)
expandable
usingquad SPI
I²C, SPI,UART,
I²C,SPI, UART,
LIN,
I²C,SPI,UART,
CAN
FSUSB 2.0, I²S,
CAN
.
16to24 UDBs
(UniversalDigital
Blocks)
4to 8UDBs
FSUSB2.0
16digitalPSoC
blocks
I²C, SPI,UART,
LIN, CAN,
FS USB2.0, I²S
20 to 24UDBs
I²C, SPI, UART,
LIN, BLE (opt.),
FS USB2.0 (opt.
host & device)
0 to 12UDBs
12
1 Delta-Sigma
ADC(6 to 14-bit)
1 Delta-Sigma
ADC(8 to 20-bit)
1 SARADC
(12-bit)
1 Delta-Sigma
ADC(8 to 20-bit)
1 SAR ADC
(12-bit) 1 MSPS
131 ksps @
8-bit;
192ksps @
12-bit;
1 Msps@ 12-bit;
192 ksps
@12-bit;
1 12 BitVoltage
Mode DAC
1 Sigma-Delta
ADC (for
capacitive
sensing)
Up tofour DACs
(8-bit)
Up totwo DACs
(7 to8-bit)
2 SARADCs
(12-bit)
1 Msps@ 12-bit;
Up tofour DACs
(8-bit)
Up totwo DACs
(6 to 8-bit)
Up to64 I/O
Up to72 I/O
Up to98I/O
Up to72 I/O
Operation: 1.7
V to5.25 V
Operation:0.5 V
to 5.5V
Operation:1.71 V
to5.5 V
Operation: 2.7 V
to 5.5V
Active:2 mA,
Active:1.2 mA,
Active:1.6 mA,
Active:2 mA,
Sleep: 3μA
Sleep:1 μA,
Sleep:1.3 μA,
Sleep:2 μA,
Hibernate: ?
Hibernate:200
nA
Hibernate:150
nA
Hibernate:300
nA
On-chipSWD,De
bug
On-chipJTAG,
SWD, SWV,
RequiresICE
Cubeand
FlexPods
Up to 104 I/O
Debug,Trace
CY8CKIT-001
Development
Kit
CY8CKIT-001De
velopment Kit
CY8CKIT-04040
00 PioneerKit
CY8CKIT-001
DevelopmentKit
CY8CKIT-030De
velopmentKit
CY8CKIT-04242
00 PioneerKit
CY8CKIT-050
DevelopmentKit
CY8CKIT-04342
00MPrototyping
Kit
CY8CKIT-059
PrototypeKit
CY8CKIT-062-B
LE PioneerKit
CY8CKIT-044
4200MPioneer
Kit
CY8CKIT-046
4200LPioneer
Kit
CY8CKIT-049
4100Prototype
Kit
13
2.3 Peripheral Systems in Silicon
An
Intellectual Property (IP) core in Semiconductorsis a reusableunit of logic
orfunctionality or a cell or a layout designthat is normally developedwith theidea of
licensingtomultiplevendorsfor use as buildingblocks in different chipdesigns.
In today’s era of IC designs more and more system functionality are getting integrated into
single chips (System on Chip /SOC designs). In these SOC designs, these pre-designed IP
cores/blocks are becoming more and more important. This is because most of the SOC
designs
have a standard microprocessor and
lot of system functionality
which are
standardized and hence if designed once can be re-used across several designs.
In figure-2.4, a lot of the components are standardized protocols and designs – eg the ARM
bus protocols like AHB, APB, the designs like Ethernet, SPI, USB , UART core etc. All
of these can be designed stand alone as IP cores/blocks and can be licenced to multiple
design houses and for different designs.
Figure-2.4 System Peripherals in Silicon
IP cores are generally licensed aseither Soft IP cores or Hard IP cores.
➔
Soft IP cores are IP blocks generally offered as synthesizable RTL models. These
are developed in one of the Hardware description language like SystemVerilog or VHDL.
Sometimes IP cores are also synthesized and provided as generic gate level netlist which
can be then mapped to any process technologies. This also falls under Soft IP cores. The
advantage of Soft IP cores is that those can be customized in the back end Placement and
14
Routing flow by a consumer to map to any process technologies.
➔
Hard IP cores on the other hand are offered as layout designs in a layout format
like GDS which is mapped to a process technology and can be directly dropped by a
consumer to the final layout of the chip. These cores cannot be customized for different
process technologies.
Generally digital logic cores are developed and licensed as Soft IP cores. eg: a DRAM
controller IP, Ethernet MAC IP, AMBA bus protocol IPs etc.
Analog and Mixed signal logic designs for serdes, PLLs, ADC or DAC, Phy layer logic
for DDR, PCIE etc are generally developed and licensed as Hard IP cores.
2.4 Validation tests for System Resource Peripheral
The strategy for System Resources is summarized as follows:
➔
System Resources is part of the core-platform bus that makes HOBTO IP plug&play
possible.
◆
Intended products have a wide variety of current, area, speed, and feature targets.
System Resources is a soft IP with many design-time configuration options controlled by
HOBTO parameters. Optional components carry no area overhead when not implemented in
a product.
◆
System Resources provides a stable set of platform-wide signals that enable
peripherals to be designed and easily reused on multiple products in the platform.
◆
System Resources reduces product cycle time for HOBTO derivatives by reusing
design, verification, and test vectors. This reuse also significantly reduces defects.
➔
IP in 40nm variant of version 1 are generally supported by version 2 with minor
modification.
◆
DeepSleep-capable IP require a small change to separate the resets use for retention
flops in Active domain from flops in DeepSleep domain.
◆
Memory integration should use the new memory power control bus (mem_lp_ctl) for
best compatibility.
➔
Adherence to a strict hierarchy of control:
◆
First, Power System hard-IP brings up power to a known-good state (Power Chapter)
◆
Second, Power Mode Transition Sequencer runs only when power is known good
(Power Chapter)
◆
Third, known-good Clocks are released to the system (Clocks Chapter)
◆
Fourth, reset is released to the system
➔
The above text pertains mainly to power up and reset events, but the same hierarchy
of control is adhered to in all other power mode transitions:
15
◆
No reset de-assert before known-good clocks
◆
No clocks to the system before known-good power and clocks
◆
No power mode sequencing before known-good power
➔
System Resources circuits are designed from the beginning with a noise isolation
strategy to minimize interference between System Resources components and the rest of the
system.
➔
Analog circuits outside System Resources requiring core voltages with special
properties (low noise, non-standard voltages, etc.) generally include local regulators as part
of the IP. These are not generally included in System Resources, with some exceptions.
➔
Version 2 System Resources is not designed with an ASIL target.
➔
Software compatibility to Version 1 is an important objective.
◆
Programming model of existing features using PDL are not changed. In most cases,
the hardware interface is unchanged. In a few cases, existing PDL functions require
modification to abstract hardware changes.
◆
New features have inevitable impact on software, such as those implementing the
ARM Power Control Architecture.
System Resources power components include:
➔
Support for global power modes: ACTIVE, SLEEP, DEEPSLEEP,
DEEPSLEEP-RAM, DEEPSLEEP-OFF, HIBERNATE, OFF w/Backup, and XRES.
➔
Multiple regulator options to span the required voltages and regulator types needed
for the product portfolio.
◆
Regulator Set A is like version 1 and comprises a Linear Core Regulator which
requires an external capacitor and options for switching regulators, including a 30mA SISO
buck and 60mA SISO buck.
◆
Regulator Set B is like previous IOT BLE products and comprises a buck regulator
(CBUCK) that regulates to an intermediate voltage, a digital step-down regulator (D-SDR),
optional BLE RF step-down regulator (RF-SDR), and optional power amplifier regulator
(PA-LDO)
➔
Mode transition logic including ‘sensitive’ asynchronous logic.
➔
Brownout detection. The internal regulator input and output voltages are monitored
by brown-out detectors (BOD). The detector on the regulator input provides robust
brown-out detection. The regulator output voltage is also monitored it has a gray area and is
not guaranteed to initiate a reset if the logic crashes.
➔
Low/High Voltage detectors with user-specified threshold for monitoring the external
supply.
System Resources clock components include:
16
➔
Standard platform clock features that require no external components:
◆
Internal Main Oscillator (IMO) at a fixed 8MHz frequency
◆
Internal High-speed Oscillator (IHO) at a fixed 48MHz frequency
◆
Internal Low-speed Oscillator (ILO0) at a fixed 32.768kHz frequency
◆
Frequency-locked loop (FLL) for logic clocking up to 100MHz
◆
Additional high frequency clocks can be generated by division
➔
Optional clock features
◆
External crystal oscillator (ECO) which requires an external crystal.
◆
Redundant Internal low speed oscillator (ILO1) for clock supervision
◆
Precision Internal Low-speed Oscillator (PILO) intended to replace an external
crystal for Bluetooth/BLE.
◆
Up to 15 PLLs with up to 200MHz output frequency.
◆
Digital clock supervision
◆
Digital clock calibration logic to compare the relative frequency of two clocks
System Resources reset components include:
➔
Reset cause detection for some resets.
➔
Power-related resets cannot be individually distinguished.
System Resources contains optional backup logic:
➔
Backup logic can be implemented in a separate battery-backup voltage island
(vbackup) or in the main unregulated voltage island (vddd).
➔
Backup domain contains the following major components
◆
Watch Crystal Oscillator (WCO) that requires an external 32.768kHz crystal
◆
Real-Time Clock (RTC)
◆
Backup Registers (BREG) to hold a small amount of application state. An
unregulated backup memory is compatible with the platform, but not planned for
implementation.
17
CHAPTER 3
COMMUNICATION BLOCK
Various blocks of DUT communicate with the PC through various protocols. Some of the
protocols use din industry are I2C, SWD, SPI, CAN, etc. The following section discusses
about the design and functionality of internal blocks of DUT board.
3.1 Protocols in Validation
At interface between DUT and dutcomm (pioneer bridge), communication plays an
important role.
The interface has an intelligent system that detects the speed at which IP communicates and
expects the same speed selection from the dutcomm side too.
Figure-3.1 DUT and dutcomm interface
Two protocols widely used are I2C and SWD.
The comparison between the two is done and studied.
Table 3.1 Protocol Comparison
I2C
SPI
SWD
2-wire protocol
4-wire protocol
2-wire protocol
One wire for the data
(SDA) and other wire for
the clock (SCL).
MOSI (master out slave in),
MISO (master in slave out),
SCL (a serial clock which
produces by the master) and
SS (slave select line which
use to select specific slave
during the communication).
SWD allows for star
topologies
Upto 5Mbps
Upto 10Mbps
Upto 50Mbps
1.2V to 5.0V
2.5V to 5.0V
1.2V to 5.0V
18
3.2 Automating the Protocols
The protocol support is available at the hardware side. To access these functionality, an
object is accessed which calls Perl script APIs and does the commands as per the received
packet.
The tests performed for protocols were at different voltages and gave the results as per the
algorithm.
The slave master combination for the DUT and dutcomm is done for validating protocols in
the silicon. Figure 3.2 shows the master slave combination of DUTs over the I2C bus.
Figure-3.2 Protocol validation set-up
19
CHAPTER 4
AUTOMATION FRAMEWORK ARCHITECTURE
Automation in the industrial workplace provides the advantages of improving productivity
and quality while reducing errors and waste, increasing safety, and adding flexibility to the
manufacturing process. In the end, industrial automation yields increased safety, reliability,
and profitability.
Industrial automation is the control of machinery and processes used in various industries by
autonomous systems through the use of technologies like robotics and computer software.
Industries implement automation to increase productivity and reduce costs related to
employees, their benefits and other associated expenses, while increasing precision and
flexibility.
With the Industrial Revolution came mechanization, which brought cheaper and more
plentiful goods. Generally, the mechanical processes in industries were faster and produced
greater quantities of goods but still required skilled workers. Not only did machines require
operators but when errors occurred, they would waste materials, cause production issues and
even damage equipment.
With the arrival of automation, control loops were added to machine operation. These can be
open control loops that allow for human input or closed loops which are fully automated.
Industrial control systems (ICS) allow for monitoring and control locally and remotely. With
these increasingly advanced control mechanisms, industries can operate 24 hours a day.
Productivity has increased, errors are reduced and quality is improved. However, automation
does have some negative impact, including high initial costs, reduced worker employment
and the elimination of some ethical human oversight. As automation continues to advance
and gain popularity in new industries, it is possible to see these events increase.
Recent advancements in automation in industrial production are focused on flexibility and
quality. Manufacturing flexibility not only allows for more product types, but also lets
consumers order customized products that are automatically produced.
4.1 Introduction to Automation Framework
Automation framework developed includes four major layers:
1.
Software Layer
a.
GUI
b.
Test scripts
c.
Dutcomm Libraries
20
d.
Programming communication object Libraries
2.
Hardware Layer
a.
DUT
b.
Dutcomm board
3.
Firmware Layer
a.
DUT test FW
b.
Dutcomm Master FW
c.
Dutcomm Slave FW
The framework is displayed in figure-4.1
Figure-4.1 Automation framework
Automation Set-up:
1.
Software Used:
a.
Visual Studio Code (VS code)
b.
Modus ToolBox (MTB)
c.
Cypress Programmer
2.
Hardware Used:
a.
Miniprog-4 : For SWD, I2C, UART protocols.
Figure-4.2 Miniprog-4
21
b. Dutcomm Board: USed for communication between the PC/Framework and
Device under test (DUT)
Figure-4.3 Dutcomm board
c. PSoC-6 : Used as a controller and secondary slave for I2C
Figure-4.4 Psoc-6 IC
d. Psoc-5 : Used as I2C master and main processor chip
Figure-4.5 PSoC-5 IC
e. PSoC-6 WiFi BT Pioneer Kit
22
Figure-4.6 Wi-Fi BT Pioneer Kit
f. Pre-silicon Validation Set-up
Figure-4.7 Pre-silicon FPGA set-up
g. Post-silicon Validation Set-up with Dutcomm
Figure-4.8 Validation board set-up after fabrication
23
4.1.1 Validation Requirement Document (VRD)
The VRD is an excel sheet. It contains the list of all the tests to be performed on the
device. The tests are grouped depending on the functionality and IP specific.
Separate sheets according to the test flow set-up are made to configure the hardware
for each test cases. The VRD acts as the feed for running the test cases and
generating reports. It also has logs attached which helps in debug.
Figure 4.9 VRD
In this document each row represents a test case with the IP Block which is the
general format of the test case, Test Name which should be unique per row per flow,
Pass and Fail Condition movement, Test Setup which describes the hardware
configurations of device during the test case execution,, Param set defines the set of
parameters needed as shown in Figure 4.2.
Figure
4.10 Test set-up selection
4.2 Comparison
The framework developed is compared with the earlier framework and the comparison table
is given below:
Table-4.1 Framework Comparison
#
Decision Factor
New Framework
Existing Framework
1
User knowledge
Exists
Exists
2
Team Dependency
None (home grown)
Different team product
4
Dev/Support team
Being Built up
No defined Support
24
5
Python version
Posted to Py3.7 .
Py3.6 framework exist (but
Needs almost similar
porting effort owing to
EXTERNALS folder
dependency)
6
TestRail Interface
Exists
Not existing in current
versions released. Can be
inherited.
7
Input Interface
Excel based
Text file based
8
GUI for Users
Exists
Not existing in Py2.7
versions released. Can be
inherited.
9
Gitlab Support
Exists
Not existing
10
Debug time
Separate log file for each
test case.
No separate log file. Need
to trace the error in whole
log.
11
Test Case run time
For System Resources: 1
minute
1min + Extra time to check
scope output
25
CHAPTER 5
RESULTS
5.1 Protocol Testing
I2C and SWD were tested and taken at 3 different voltages:
I2C: Test cases were written to continuously read and write through I2C protocol. The flow
of instructions starts with sending the 16-bit data packet from python script to dutcomm.
This transfer of packet takes place through a communication object which acts as a handler
for communication between PC and dutcomm pioneer board. Once the board receives the
data packet, it is then sent through wires to the device under test. The data packet sent by the
dutcomm board is in 8-bits and each bit represents an instruction. Depending on the data bit,
DUT performs operations. The operation selection is done based on the switch case that is
selected depending on the received bit through dutcomm. The switch case resides in the
firmware of DUT.
Once the operation is selected, I2C master-slave functionality is performed and the
waveform has been captured below. The above test is run for three different voltages i.e
3.3V, 2.4V and 1.8V.
1. At 3.3V
Figure-5.1 I2C waveforms for DUT operating at 3.3V
2. 2.5V
26
Figure-5.2 I2C waveforms for DUT operating at 2.4V
3. 1.8V
Figure-5.3 I2C waveforms for DUT operating at 1.8V
The test case was run through the GUI made for automation. The time taken for running the test case
was reduced by 1.75 times and the response time was faster as compared to the earlier framework.
SWD: The test case to program the dut through dutcomm is done using SWD (Serial wire debug)
protocol. Regression testing was done at three different voltages i.e 3.3V, 2.4V and 1.8V. The GUI
proved to be robust and the engineer was able to complete the test cases properly.
1.
3.3V
Figure-5.4 SWD waveforms for DUT operating at 3.3V
2. 2.4V
Figure-5.5 SWD waveforms for DUT operating at 2.4V
27
3. 1.8V
Figure-5.6 SWD waveforms for DUT operating at 1.8V
I2C logs :
Figure-5.7 Logs for Automation framework test run
28
Automation Framework Home Page:
Figure-5.8 Home Page screen of automation GUI
29
CHAPTER 6
CONCLUSION AND FUTURE SCOPE
After discussing the design of Automation framework and successfully testing the
IPs, the project can be concluded. The process and methodology implemented to run
the automated test cases with minimal efforts are presented and concluded. Finally,
the future scope and learning outcome of this project are discussed in subsequent
sections.
6.1 Conclusion
Chipmaking industries cannot release faulted devices to customers because of the
losses
involved when device malfunctions during its operating cycle. Thus,
validating the silicon is one of the important phases in device manufacturing cycle.
But the additional cost and time should be kept to a minimum. As mentioned in the
first objective of this project, the test environment like the preparation of VRD, IP
programs, pattern file generation, voltage level setting, pin assignments etc. is done
and generates firmware which is then loaded on DUT. Once loading is complete,
GUI is used to run the test cases and get the logs. Thus, first objective of this project
is met.
Second objective of this project is to test the protocols and check the robustness of
the automation framework. Various
blocks of DUT are tested and continuous
regression tests are run to make the GUI suitable for all situations.
Third objective of reducing the documentation work for the IP engineers is met by
introducing the TestRail integration. Continuous development of the framework is
done through GITLAb integration.
6.2 Future Scope
The GUI and framework is a strong tool which can be used for debug purposes. This
tool will help engineers to save time during debug phase and will help them to spend
more time to understand and do advancements in the framework and validation
strategy.
30
BIBLIOGRAPHY
1. K. Basu and S. Kundu, Post-Silicon Validation and Diagnosis, 2016 29th
International Conference on VLSI Design and 2016 15th International Conference
on Embedded Systems (VLSID), 2016.
2. Wai Loon, Hock Thien, Bian Sim, Pre silicon validation methodology
breakthrough for 3D IC, INTERNATIONAL TEST CONFERENCE 1, 2018 IEEE
3. Kai-Hui Chang, Igor L. Markov , Valeria Bertacco, Automating post-silicon
debugging and repair, IEEE/ACM International Conference on Computer-Aided
Design, Digest of Technical Papers, 2007
4. Subhasish
Mitra,
Sanjit
A.
Seshia,
Nicola
Nicolici,
Post-Silicon
Validation-Opportunities, Challenges and Recent Advances, Verification, B8.1
Reliability, Testing and Fault Tolerance, B 8.2 Performance Analysis and Design
Aids, 2010
5. Keerthikumara Devarajegowda, Wolfgang Ecker, Meta-model Based Automation
of Properties for Pre-Silicon Verification, IFIP/IEEE International Conference on
Very Large Scale Integration (VLSI-SoC), 2018
6. A. Lathwal, A Literature Review on Automation Testing Using Selenium+Sikuli,
Research Anthology on Cross-Disciplinary Designs and Applications of
Automation, pp. 602,606, 2022
7. Y. Xin and Q. Wang, Web VI Layout Issue Detection in Internationalization
Automation
Testing,
2021
13th
International
Conference
on
Wireless
Communications and Signal Processing (WCSP), Oct. 2021.
8. S. D. R. Konreddy, The Impact of NLP on Software Testing, Journal of University
of Shanghai for Science and Technology, vol. 23, no. 08, pp. 295, 304, Aug. 2021
9. W. Junmei and Y. Chengkang, Automation Testing of Software Security Based on
BurpSuite, 2021 International Conference of Social Computing and Digital
Economy (ICSCDE), Aug. 2021.
10. E. Pelivani and B. Cico, A comparative study of automation testing tools for web
applications, 2021 10th Mediterranean Conference on Embedded Computing
(MECO), Jun. 2021.
11. S. Zhang, D. Fan, J. He, and P. Zhang, A New Approach for End to End
31
Automation Testing Platform with Cloud Computing for 5G Product, 2021
International Conference on Computer Engineering and Application (ICCEA), Jun.
2021.
12. K. N. Mohan and D. R. K. P, Scriptless GUI Automation Testing Tool for Web
Applications, International Journal of Recent Technology and Engineering
(IJRTE), vol. 10, no. 1, pp. 216, 219, May 2021
13. T Kishan Singh, Pavithra H, Test Case Recording using JavaScript for
Automation Testing , International Journal of Recent Technology and Engineering,
Vol 10 (1), pp. 153-157, 2021
14. Roopesh R, Dr. Manimala S, Test Coverage Enhancement Using Hybrid Modular
Approach For Web Based Application, International Journal of Engineering
Applied Sciences and Technology, Vol 6 (1), 2021
15. C. Klammer and R. Ramler, A Journey from Manual Testing to Automated Test
Generation in an Industry Project, 2017 IEEE International Conference on
Software Quality, Reliability and Security Companion (QRS-C), 2017, pp.
591-592,
16. Goshu Y. Y. Kitaw D. (2017). Performance measurement and its recent challenge:
A literature review. Int. J.Business Performance Management, 18(4), 381–402
17. Kaur M. Kumari R. (2011). Comparative study of automated testing tools:
Testcomplete and quicktest pro.International Journal of Computers and
Applications, 24(1), 1–7.
18. Raulamo-Jurvanen, P., Kakkonen, K., & Mantyla, M. 2016. Using Surveys and
Web-scarping to Select Tools for Software Testing Consultancy. In Proceedings of
the 17th International Conference on Product-Focused Software Process
Improvement.
19. Uppal N. Chopra V. (2012). Design and implementation in selenium ide with web
driver.International Journal of Computers and Applications, 46, 8–11
20. Wang, S., & Offutt, J. (2009). Comparison of unit-level automated test generation
tools. In Proceedings of the International Conference on IEEE Software Testing,
Verification and Validation Workshops ICSTW'09. IEEE Press
21. https://www.thefreedictionary.com/validation
32
22. https://guides.rubyonrails.org/active_record_validations.html
23. https://docs.aws.amazon.com/acm/latest/userguide/email-validation
24. https://docs.flutter.dev/cookbook/forms/validation
25. https://www.intel.com/content/www/us/en/collections/content-type/memory-valida
tion-results.html
26. https://dictionary.cambridge.org/us/dictionary/english/validation
27. https://laravel.com/docs/9.x/validation
28. https://pro.arcgis.com/en/pro-app/2.8/help/data/geodatabases/overview/validationattribute-rules.htm
29. https://graphql.org/learn/validation/
30. https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/validation
33
Report Plag
ORIGINALITY REPORT
8
%
SIMILARITY INDEX
7%
INTERNET SOURCES
3%
PUBLICATIONS
4%
STUDENT PAPERS
PRIMARY SOURCES
1
En.wikipedia.org
3%
2
people.eecs.berkeley.edu
2%
3
community.infineon.com
1%
4
www.gosemiandbeyond.com
1%
K. R. Aljazeera, R. Nandakumar, S. B. Ershad.
"Design and characterization of LBlock
cryptocore", 2016 International Conference on
Signal Processing, Communication, Power and
Embedded System (SCOPES), 2016
1%
5
Internet Source
Internet Source
Internet Source
Internet Source
Publication
6
Submitted to National Institute of Technology
Jamshedpur
<1 %
Keerthikumara Devarajegowda, Wolfgang
Ecker. "Meta-model Based Automation of
Properties for Pre-Silicon Verification", 2018
<1 %
Student Paper
7
IFIP/IEEE International Conference on Very
Large Scale Integration (VLSI-SoC), 2018
Publication
8
Submitted to The Open University of Hong
Kong
Student Paper
Exclude quotes
On
Exclude bibliography
On
Exclude matches
< 10 words
<1 %
IFIN HR- 2022
24-05-2022
CERTIFICATE
To Whom It May Concern
Formal Data:
Student Name:
TANISHA SHARMA
Institution:
SRM IST, Faculty of Engineering and Technology, Kattankulathur
Organization:
Infineon Technologies India Pvt. Ltd.
Project Instructors/ Managers: Marrivagu Vijay Kumar
Evaluation of work:
TANISHA SHARMA was working as a Student Trainee with us from 05-Jul-2021 till 31-Mar2022 and is working on project “Automation Framework for Silicon Validation”.
TANISHA SHARMA is an avid and independent learner, has good analytical & application skills
and has shown exemplary performance during the internship period.
We wish TANISHA SHARMA a long fruitful career and success in future endeavors.
For Infineon Technologies India Pvt. Ltd.
Thara Aiyanna
HR Manager
Infineon Technologies India Private Limited
Company Registration Number : 22413
Postal Address : 11 Mahatma Gandhi Road, Bengaluru 560 001
Internet www.infineon.com
Tel +(91) (80) 3927 1000
This is to certify that
Tanisha Sharma,Dr. K Suganthi
has presented a paper titled
Design and Simulation of Multi-gate Spin-FET using TCAD
CERTIFICATE OF PARTICIPATION