REDDY CHANDRASEKHARA

+91-7569207972 , [email protected] , 1st-jan-2023

CTC: Rs. 36 lacs/anum, Take home: Rs. 2,50,000/- pm

ECTC: Negotiable,
Notice period: immediate join

Experience: 13Y, SOC Verification manager.

SOC Verification Manager with SystemVerilog, UVM methodology, Formal verification, GLS simulation,
Power Aware verification.Can train the team members on SystemVerilog, UVM-methodology, subversions/p4,
Systemc, PCIE, DDR4, FPGA-tools, 4G/5G-network, satellite-technology, fiber optic technology and
cryptography.

EDUCATION:
GATE-2003( EC-123164 ) : 98.62 percentile,
B.Tech ECE FDH ( 49531 ) from REC, Kakatiya university, Warangal, 61% , 2000

SKILLS:
Windows11, Linux-RHEL8.4 , Linux-SUSE-SLED-15-SP3,
Operating Systems Windows-TOGO, RHEL-Persistence-drive, SUSE-SLED-
Persistence-drive
Programming Languages C, C++, ARM-Assembly
HDL Languages VHDL, Verilog, SystemVerilog,
HVL languages SystemC, BluespecSV
SOC
Verification UVM, VMM, UVMC-package
Methodologies
Scripting languages python, perl, Ruby , c-shell, gmake
ClearCase, CVS, SVN, Perforce/ICMP4, accurev, git and
File Version Control tools
synchronicity
Symplicity synthesis tool, Xilinx Vivado-ML-2021.3-Enterprise,
EDA synthesis tools
Intel-Quartus-pro-21.3 FPGA synthesis.
CoMET, METeor, SGCanvas modeling tools
EDA Modelling tools
Cadence IUS IMC, Synopsys VCS DVE Verdi, Modelsim simulators
EDA Simulator tools
EDA Coverage analysis
Cadence IMC, Synopsys DVE/VERDI
tools
Jasper Gold, Cadence: ABV-application, coverage application.
Formal verification tool
CDC application
ARM CA53 64-bit CPU with CHI-interconnect, ARM1176 with
CPU
AXI-bus, CM0 with AHB-bus
SATA/SAS-bus, PCIExpress-bus, AXI-bus, AXI-stream bus, CHI-
Bus protocols Bus, CHI-interconnect, ACE-bus, IOSF-bus, PMBus, SRS-
bus ,SDP-bus, FTI-bus
TLM modeling SystemC-TLM, UVM-TLM
Memory protocols DDR3, DDR4 PHY, DFI-protocol
DECT wireless/cardless PHY protocol
WLAN(WIFI)-PHY, MAC layers
Theory: LTE/4G RLC, RRC, MAC, PHY, OFDMA, W-CDMA
Wireless protocols
layers.
Theory : Base station TX/RX, user equipment TX/RX using
OFDMA
 FIPS PUB AES-128/256,
DECT DSC 128-bit,
Cipher (Encryption)
2G/3G KASUMI, and WIFI CCMP.
protocols
4G/LTE security architecture,
Fiber optic authentication protocol, etc.
Aero space protocols DO-254 standard, ARINC429, AEH
SDH transport, OTN transport, STM1 mappers, fiber optic rings,
Fiber optic protocols
etc
IPV4, IPV6, packet switch & router, Ethernet to LTE/4G/3G packet
Ethernet protocol
conversion
Memory coherency ARM CA53 multi core(16) cache coherency protocol & snoop
protocols control protocol
PLL ADPLL design.
C,C++ Compilers &
ARMCC, ARMCL, ARM-DS, MSVC
linkers.
Assembly language ARM assembly coding with ARM-V7-instruction set.
Assertions Systemverilog based Assertions coding
RTL Code coverage analysis,
Coverage systemverilog based functional coverage analysis,
cover groups bins analysis, cover properties analysis.
IP level verification
SOC level verification,
UVM/VMM/OVM-methodology based verification
CPU based SOC verification with assembly/C/C++ code based test
SOC verification expert
cases and SV-test cases.
Multi-core CPU with cache-coherency SOC verification.
SV & SystemC mixed modules verification,
UVM-TLM & SystemC-TLM mixed modules verification.
--Complete 5G/4G/LTE network all protocols theoretical knowledge,
--Complete fiber-optic SDH, OTN all protocols theoretical knowledge.
--Good theoretical knowledge on satellite hardware design & flight
hardware design
--complete theoretical knowledge on all type of satellites, little on rocket
science and astronomy.
Theoretical knowledge
--Complete theoretical knowledge on GPS system of satellites:
expert
space segment satellites design, ground segment GPS control stations
functionality, User segment GPS receiver architecture, hardware and
software.
Cell phone network aided GPS,
Satellite aided GPS,
Regional GPS with limited no. of Geo-stationary satellites.
Can Create bootable/installable/persistence USB-Pen-drive for windows
and any linux;
Can install operating systems like Windows11, Linux-RHEL8 , linux-
SUSE and can install systemc, perforce, vivado fpga tool , quartus fpga
tool on SUSE/any linux;
IT skills Can run operating system from USB-pen-drive like WINDOWS11-
TOGO, RHEL-persistence, SUSE-SLED-persistence
Can install and use secure-key for windows login and online login
authentication

Cinematics skills Adobe’s After Effects : adding visual effects(VFX) to videos

COMPANIES:
9.CHIPLOGICTECH, from july-2021 to still ( client renesas , Memryx )
8.AMD, from march-2021 to may-2022.
7.Incise Infotech Pvt Ltd, from June-2020 to march-2021 ( Client NXP , ADI )
6.Appex-Semiconductors from march-2019 to may-2020( client Maxlinear , Cypress )
5.Progneur consultancy from june-2017 to aug-2018 ( Client Intel )
4.EInfochips from April-2016 to April-2017 ( clients altera/intel , rockwell collins , teradyne )
3.Graphene Semiconductors from Oct-2013 to march-2016 ( clients rambus , sandisc , broadcom , avago )
2.GlobalEdgeSoft dec-2009 to jan-2012 ( clients LSI , infeneon/intel )
1.KPITCummins , june-2006 to june-2008 ( agere systems , bluespec )

PROJECTS DETAILS:
MemryX , Inc : Oct-2022 to Jan-2023
Project Camera Interface Pixel format converter verification
Technology UVM-methodology , AI (artificial intelligency)
Role Team member or individual contributor

Tools & Xcelium, xrun, simvision, IMC, systemverilog

language
Team size 2

Synopsis
The pixel-format-converter is a camera interface that converters pixel data from
RGB888/RGB565/YUV422/FP32/BF16-format to GBF80 format and vice versa. It is a
generic/parameterizable and scalable and configurable design. A typical configuration and
scalling use 32-simultaeous packers that run in parallel. It has two paths: 1)ingress path that
converts other pixel format into GBF80 2)egress path the converts GBF80 to other pixel
formats.Register are accessible using Xbus-interface. Ingress and egress path use AXI-
interface, FMEM-interface. It will be used in one of the AI-core(artificial inteligency) chip for
pattern recognition , image processing applications , and AI-applications.

My work:
Build SV+UVM testbench from scratch, coded RAL model manual, all other testbench
components code manual. No automatic script used to build the testbench and no script is
used to run the simulation,
Coded no of testcases, run the tests, run regression, analyzed code coverage, analyzed
functional coverage.

Client company : Memryx , [email protected]

Service company : ChiplogicTech, CL_PERM_047 , [email protected]

Renesas Electronics: July-2021 to oct-2022

Project Formal verification of LDO controllers, and training the team on formal
verification.
Technology Formal verification

Role Team member or individual contributor

Tools & JasperGold , systemverilog

language
Team size 1

Synopsis
LDO (low dropout voltage regulators) controllers are a generic 5/7-state state-machine
RTL design with many inputs and many outputs. The LDO-controller are two types
DVS and NON-DVS. Each LDO type has a set of parameters , i.e it is a
generic/parameterizable design. The purpose of LDO-controllers is to scale up/down
analog voltage by controlling digital data input. During reset the digital data of analog
circuits can be set to a defined default value. Later the digital data will be stable or
 slight change can be done. Later during DVS-state the digital data can be scaled
up/down at specific configurable slew rate. The bahavior of LDO-controller is changed
based on configuration and paramters passed during instantiation of design.The LDO
controller is verified using jaspergold formal verification tool, using a script and excel-
sheets called as DIA_FV_FLOW. Systemverilog assertions and cover properties are
used to verify the LDO-controllesr using jasper gold formal verification tool.The
assuptions are coded in *.tcl file that can restrict the input stimulus that formal tool can
generates. No. of applications of jaspergold tool like connectivity check app, coverage
app , assertions/propeties prove app , register write/read app , etc are used in this
project.

My work:
I made generic/parameterizable formal testbenches, using systemverilog, to verify the
generic/parameterizable dvs/non-dvs LDO-controllers. An excel-sheet is filled with
preconditions and consequences of assertions and signal assignments.A script
processed the excel-sheet and generates no. of assertions that will be compiled and run
by jasper gold tool.I debugged assertions failure and reported design issues. The
property prove app , coverage app , connectivity app are run to verifiy LDO controllers
(DVS,NON-DVS) in different parameters set and different configurations.

I did trained a team of 10 people on formal verification. How to make formal

testbenches , write assumptions, write assertions, write cover properties, run different
apps of formal tools, etc.

Client company: Renesas Electronics , DS NO. A5138747 , [email protected]

Service company : ChiplogicTech, CL_PERM_047 , [email protected]

Advanced Micro Devices: Sep-2021 to Dec-2022

Project Perforce integration of multiple CLs from a trunk/depot into a branch
Technology Perforce

Role Team Lead

Tools & Perforce

language
Team size 3

Synopsis
The DataFabric is an SDP-bus interconnect.The depot/trunk/repository is used to
manage all files of DataFabric project. The design RTL files, testbench sv+uvm files,
other docs and libs are kept in the depot/trunk.When the project complete a specified
set of features then a branch will be created from depot/trunk. Later if more files are
updated in depot/trunk with new features then the changes(changelist CL) will be
integrated from depot/trunk to the branch.

My work:
Regularly integrate multiple CLs from depot/trunk of project to a branch of project.
 The branch is delivered to SOC teams from DataFabric team

Company: Advanced Micro Devices

ID : 50017115 , [email protected],

Advanced Micro Devices: May-2021 to Aug-2021

Project The DataFabric (SDP-bus interconnect) verification and deployment
Technology CPU design, Coherency, Multi-Core SOC , SDP/FTI-bus protcols

Role Team Lead

Tools & DJ-flow(Ruby script), UVM, SV

language
Team size 5

Synopsis
The DataFabric is an SDP-bus interconnect. The CPU/GPU-Masters, IO-master/slave,
Memory(UMC), cohrent/non-coherent slaves etc. connect to DataFabric. The
DafaFabric contains a number of Nodes. The node to node packet/data transfer is done
using FTI-bus protocol. The external components do data transfer to DataFabric using
SDP-bus protocol. The SDP/FTI-bus protocols are based on packets transfer. Each
packet has no. of fields like address, data, id, etc. There are multiple channels in SDP-
bus, and in FTI-bus also. The DataFabric is scalable, parameterized, and configurable.
It is used in number. of SOC projects.The DataFabric supports coherent/non-coherent
data transfers, parity checking , Ordering, PCIE-transactions, Die-to-die data transfer,
Probe-transactions, credit based transfers, Probe-filters,etc, and supports multi-core( 4
to 128 CPUs) coherency.The datafabric is being used in Ryzen and EPYC SOC that are
used in laptop/desktop/server products.

My work:
Debug few RTL/TB issues that are failed in SOC projects and reported by SOC
teams.Regularly do deliver(deployment) of DataFabric RTL with given set of features
to a given SOC team.There are 12-15 SOC projects that use the DataFabric with
different features set.

Company: Advanced Micro Devices

ID : 50017115 , [email protected],

Advanced Micro Devices: April-2021 to May-2021

Project The Advanced Programmable Interrupt Controller verification
Technology Micro electronics, CPU design

Role Team Lead

Tools & DJ-flow(Ruby script), Perforce(ICMP4), UVM , systemverilog

language
Team size 5

Synopsis
 The interrupt controller receives different type of interrrupts from external sources,
from CPUs, from timers, interrupts originated inside itself. The received interrupts are
registered, later it will send the interrupt as a message to CPU using SDP-bus protocol
packets.It is scalable , parameterized and configurable module. It mask, prioritize and
route the interrupts to CPU or other interrupt controller.one or more instances of
interrupt controllers will be used in a typical SOC. The interrupt controller, as an IP, is
used in no. of SOC projects with different scale, different parameters, different
configuration. DJ_flow is ruby script that brings files of design, libraries, testbench etc
for compilation and simulation; It also prepares arguments of simulator and synthesis
tools and launch bjobs on LSF servers.

My work:
Debug few RTL/TB issues that are failed in regression of different SOC projects.
There are 12-15 SOC projects running regressions.

Company: Advanced Micro Devices

ID : 50017115 , [email protected]

Advanced Micro Devices: March-2021 to April-2021

Project Formal verification
Technology Formal verification, VC-formal

Role Team Lead

Tools & DJ-flow(Ruby script), UVM, systemverilog

language
Team size 1

Synopsis
DataFabric is an RTL module (SDP-bus-interconnect) that is used in no. of SOC
projects. The DataFabric module has no of registers.The DataFabric is verified using
formal verification in addition to functional verification. The registers of DataFabric
modules are to be verified using using formal verification. DJ_flow is ruby script that
brings files of design, libraries, testbench etc for compilation and simulation; It also
prepares arguments of simulator and synthesis tools and launch bjobs on LSF servers.

My work:
Provided a solution to make formal testbench using DJ_FLOW by re-using functional
testbench. Work given is Verify register of DataFabric using formal verification with
vc-formal tool.

Company: Advanced Micro Devices

ID : 50017115 , [email protected]

Analog Devices: Aug-2020 to march-2021

Project 5G/4G-LTE Physical layer {ECPRI+IP}-Interface design verification
Technology Design Verification, 5G cell phone network, Ethernet, ECPRI
 Role Technical Manager

Tools & System Verilog , UVM, irun simulator , GIT

language
Team size 15

Synopsis
The Physical layer of 5G/4G-LTE wireless air interface is divided into upper phy and
lower phy.The functionality of OFDMA physical layer of 5G wireless access is split at
7.x , and the data transfer from upper physical layer to lower physical layer is using
ECPRI-protocol , and the ECPRI frames are transported onto IPV4/IPV6-protocol. The
design is the {ECPRI+IPV4/V6} , It is verified using SV and UVM.

I worked as technical manager, trained all team members(15) on systemverilog and

UVM-methodology, trained on OFDMA , DFT-spread-OFDMA , 5G-wireless
networks general architecture , Coding C/SV functions for PN-sequences and other
sequences that are used in Physical layer of 5G radio access, trained on usage of
matlab for DFT/FFT computing and compression algorithms , introduced Matlab
interface to irun simulator so that at run time matlab tool produce expected data for
checking in the simulation, trained on GIT file version control system , etc.

I Architected very good testbench, the best of UVM, with time stamp generation,
OFDMA-symbol/slot/frame timings for all possible numerology of 5G-networks.
Assigned work to all team members, taken status weekly, managed good quality of
source code of testbench and review process as per DO-254 process standard, measured
the work done by all team members as work units, prepared status report , prepared
progress report as tables and graphs, prepared project report summary and lessons
learned ,etc.

Client : Analog Devices ,

Service company: INCISE infotech , [email protected] ,
IN0362

NXP Semiconductors: june-2020 to Aug-2020

Project Multi-core Safety critical SOC verification
Technology Design Verification, Safety critical SOC design, SRS-bus protocol

Role Verification Lead , Technical Consultant

Tools & Systemverilog , UVM , xrun simulator , design sync

language
Team size 20

Synopsis
The SOC is safety critical design compliance to ISO-62626 standard, suitable for automotive
applications. The design has Cortex-M4 CPU that runs firmware, works as system control
unit(SCU). The Cortex-A72 is the application processor that runs main operating system and
 applications.The system use SRS-bus protocol. The ACE/AXI-bus fields/attributes mapped
into SRS-bus fields/attributes. The Processing elements(CPUs) are grouped into different
domains called Master Domain Id , the slaves also grouped into different domains called Slave
Domain id. The Domain assignment controller assigns Master/slave domain id to the SRS-bus
fields/attributes. The c-code(firmware) of a test runs on Cortex-M4 CPU and controls clocks of
SOC , controls/configures domain assignment controller , configures security features ,
user/privileged permission etc. The SRS-bus protocol has no. of sets of signals that are useful
for Low speed pheriperals , high speed pheripherals , test purpose etc. The set of signals are
denoted using color lines : skyblue-line( low speed data transfers) , magenta line( high speed
data transfers, includes secure/non-secure, privilege/nn-privilege, master/slave domain id , etc
operations), green line( global signals: clock, reset) , red-line , etc.The connectivity block is
connected to Cortex-M4 CPU using MSI-bus( a set of signals of SRS-bus) , followed by AHB-
bus using interconnects. The connectivity block is connected to Cortex-A72 using SRS-bus
magenta line( a set of signals of SRS-bus), followed ACE-bus using interconnects.The
connectivity block contains an ethernet , SDIO , eMMC , DMA-engine, Cipher-engine, Media
transfer Bus. The connectivity block is configured using Cortex-M4 CPU , and main data
transfer is done by Cortex-CA72 CPU.

I worked as a consultant to help to team members to work on the SOC project.

I trained the team on simvision waveform viewer tool , IMC coverage analysis tool , design
sync (file version control system) , AHB-bus protocol , SRS-bus skyblue line protocol , ARM-
V8 assembly code instruction set, Configuration flow from Cortex-M4 to all other Ips, Main
data Flow from Cortex-A72 CPU to all other IPs in the SOC. I trained one of the technical
person from service company(INCISE) to work at Client company(NXP) on this safety critical
SOC project

Client: NXP semiconductors, NXF65017, [email protected]

Service company: INCISE infotech , [email protected] ,
IN0362

Cypress Semiconductors : Feb-2020 to march-2020

Project UPF power aware verification of ARM CM4-CPU based SOC
Technology VLSI chip design Verification , Embedded Real time CPU

Role Verification Lead

Tools & Systemverilog , UVM , Questasim simulator , ICMP4

language
Team size 5

Synopsis
The SOC is based on CM4-CPU of ARM with no. of other IO-devices connected to
AHB-interconnect. The design is low power controlled, There are multiple power
domains , multiple power supplies. The power intent of design is captured and described
in UPF(Unified Power Format). At the RTL simulation itself , before GLS or synthesis,
the UPF file is processed by questa simulator , and introduce additional power supply
Vdd, Vss nets , retention states , retention registers , etc as per the design low power
requirement. The testcases that are used for RTL simulation are being reused for UPF
power aware verification, but the Power supply nets are on/off randomly during
simulation time to time.
 I updated RTL testbench so that it is suitable for UPF power aware simulation.
Run Few testcases and verified that the design is working as per power intent that is
described in UPF file.

Client: Cypress semiconductors, MRRE, [email protected]

Service company: Appex-Semiconductors, AES/74

Cypress Semiconductors : 26-Aug-2019 to jan-2020

Project ARM-CM0+CM4 CPU based SOC verification
Technology VLSI chip design Verification , Embedded Real time CPU

Role Verification Lead

Tools & Systemverilog , UVM , Questasim simulator , ICMP4

language
Team size 5

Synopsis
SOC testbench is a generic and scalable to verify multi-core CPU based design.
A no. of projects use the similar testbench. There is a deisgn that use ARM-CM0 and ARM-CM4
CPUSs and other IPs connected to AHB-interconnect.The test bench supports the current design
verification.The test cases are portable from other projects due to generic and scalable nature of
testbench and testcases. More than 100 testcases are ported and adjusted such that they verify the
current design. As a derivation of the current project the CM4 CPU is removed from design and
FLASH memory also removed from design. Thus a new project with new design is verified with
the same testbench, and a sub set of testcases with little change in command line arguments and
other optional parameters. Few testcases use only SV code with API's that drive AHB-bus as if
CPU drives it. Few testcases use both C-code and SV-code. The c-code is compiled using ARM-
DS5 ARMCC, ARMCL compiler and linker, and the image is processed and loaded into
ROM/FLASH/RAM depending on requirements. The boot code is loaded into ROM always, and
it jumps to ROM/RAM/FLASH memory that contains c-test code. The c-code write into a
register that is processed by SV testbench code to end the simulation.

We ported multiple testcases from other projects into the current project and verified the design.
We analyzed the code coverage and functional coverage, Excluded many unwanted code
coverage items and functional coverage items for the current project, and make sure that both
code coverage and functional coverage is 100%. Total 850 runs of 125 tests with different seeds
as a regression meets the code + functional coverare 100%.

Client: Cypress semiconductors, MRRE, [email protected]

Service company: Appex-Semiconductors, AES/74

Maxliner : 18-march-2019 to 15-aug-2019

Project PMBus Device Verification
Technology Power electronics, VLSI chip design

Role Verification Lead

 Tools & Python, Systemverilog, UVM, Cadence xrun simulator, simvision and IMC
language
Team size 3

Synopsis
PMBus is a serial bus protocol that can be used to control power controllers.PMBus serial
communication frame format and signalling looks similar to i2c-protocol.PMBus command layer
works on SMBus physical layer for byte transfers. There are 256 possible PMBus commands and
four/more EXTENDED commands, and Few manufacturer supported commands. The
host(master) can control one/more devices using the same two wire {SCL,SDA} lines .The two
wire are wired AND with pull up loads. There are two markers START {SCL high when SDA
has high to low transition}, STOP {SCL high when SDA has low to high transition}.Each
transfer starts with START mark and ends with STOP mark.one/more bytes are transfered
between START and STOP. Each byte gets ACK/NACK to show success/faulure of transfer of
the byte.First byte is slave address to which the transfer is to be done, second byte is command,
and other bytes are sub-commands or data that are required for given command. The applications
of the PMBus host/device are Power converters, battery chargers, Mother board power supply
controllers, etc.

I verified PMBus device digital core. Made a block level testbench , listed no. of tests, coded few
testcases.Top level design has three digital cores and corresponding analog block, telemetry
block, and others. I verified PMbus device top design that contains multiple(three) digital cores
and other analog components, The design has One time Programmable a ROM/OTP. I made a
phython script that generates source code of no, of (256) PMbus Command Sequences , no. of
test sequences and test cases basic structures. I updated existing top level testbench with PMBus-
VIP integration , Coded/ported no(25) of test cases that are used to test OTP-memory controller,
GPADC controller; and coded no.(200-300) of functional coverage views; also helped to other
team members to code other testcases.

Client : Maxlinear , CON55 , [email protected]

Service company: Appex-Semiconductors , AES/74

Intel : dec-2017 to june-2018

Project Testchip verification

Technology Testchip integration automation & verification
Role Verification engineer
Tools & VCS, DVE & SystemVerilog
language
Team size 10

Synopsis
The testchip contains the actual design and additional logic. The additional logic is added to the
actual design to test the design after fabrication. The testing of a chip after fabrication is to find
bugs if any after fabrication. The actual design is an integration of MIPI-CSI-DSI-ADPLL
modules. The additional test logic is JTAG architecture, IOSF-Bus port, APB-bus port,
additional router , and bridge , VISA-archiecture. There is an automated flow to add the
additional additional/testing logic to the actual design. Similarly there is an automated flow to
build test bench as per the automated design integration.

The RTL module and additional meta-data is used by scripts to integrate the RTL module in
the next level of top RTL module in the design. Similarly test bench components are
constructed as per the need of verification. The design is pre verified, there is no need of
verification of design. The additional testing logic components also pre verified, no need to
verify them. Only the connectivity of design and the additional testing components are to be
 verified. There are few test cases to verify the connectivity of signals. There are so many (few
hundreds) of signals are to be verified for their connectivity. So the list of signals are collected
from meta-data of RTL modules that are used for integration.
For a given RTL module some of the signal are connected to next level of top RTL module,
some of the signals are not connected at all, some of the signals are driven by fixed values,
some of the signals are connected to registers, some of the signals are driven by registers, etc
type of properties of signals are there in the meta-data of an RTL module.
CI/CO/PP/OO/{I/O/B}/T/ONC/NC/PadEx/OI/… etc are signal properties There is an excel-
sheet that contains list of all signals, and also specifies the properties of each signal. The
connectivity test is build by a script. The script uses the excel-sheet of list of signals and their
properties, and write a test case code in systemverilog. The testcase that is build by a script by
using excel-sheet of signals, is used for verification. The covergroup also is constructed by
script by keeping each signal as coverpoint in it. Once connectivity test is run with coverage
enable options the coverage is accumulated from multiple runs of test. The functional
covergroup is analyzed to find if any un-covered signals are there.

I worked on
1) Given presentation on intel testchip architecture, intel IOSF-bus, intel gpio architecture,
pcie-3 bus, JTAG-architecture to ramp up the team to work on testchip.
2) run a script to build connectivity test ,
2) run the connectivity test ,
3) analyze functional coverage,
4) reported multiple bugs and reported un-covered items.
Client: Intel WWID: 11735018, [email protected]
Sponsor LnT techservices, Psno: 90000333
Service company: Progneur, Emp-ID: 170601 , PLM consultant
Intel : Sep-2017 to Dec-2017

Project Formal Verification of a design that contains multiple type of arbiters

Technology Formal verification
Role Formal Verification engineer
Tools & Jasper Gold Formal verification tool, Cadence, v2017.09 version
language SystemVerilog
Team size 2

Synopsis
The design is called TDG (Thread Dispatch Global ) unit. This unit has multiple round robin
arbiters (RRA) instances, a fixed priority arbiter (FPA), FIFOs at the input and additional
combinational circuit between RRA and FPA. TDG has 6 clients (VS, HS ASYN etc) inputs.
Based on their configuration some are multi-bit some are single bit. It has threads named as
dummy, normal, static etc. The sub modules and top module of the design are
generic/parameterizable. A formal test bench is made for each sub modules and also top
module, and are bind them. Formal test bench contains assumptions, assertions, cover
properties, cover groups, and additional code to derive some other signals. Full proof is
reported by jasper gold(JG), cadence tool. Formal engines like Ht , K , G2 , Tri etc are used by
tool while proving all properties ( assertions, assumptions, cover properties ). Tcl-tk script is
used to launch multiple sessions in the JG tool for different set of parameters of
generic/parameterizable design. Each session reported full proof formal verification. Jasper
gold has multiple application like formal property verification, CDC verification, X-
propagation verification, connectivity verification, equivalence checking, coverage un-
rechability verification, etc. to verify the design formally.

I involved in the following activities:

Writing assumptions, assertions, cover properties, cover groups, and reused SB3 type build in
score boards. The formal verification test bench coded with generic/parameterizable, additional
coding is done to derive some signal that are also used in formal verification. Written tcl-tk
script to launch multiple JG session to prove formally all possible set of design parameters. We
used formal property verification and coverage unreachability verification.
 Client: Intel WWID : 11389452 , [email protected]
Sponsor: cadence, [email protected]
Service company: Progneur, Emp-ID: 170601, Department: VLSI-service

Intel: Jan-2017 to april-2017

Project Ethernet Interface PHY verification

Technology Ethernet
Role Verification engineer
Tools & Synopsys VCS, systemverilog, ethernet-VIP
language
Team size 5

Synopsis
Intel/altera is developing ethernet IP modules to be fused into their FPGA device.
The design contains multiple ethernet interface. Each ethernet Interface supports
400G/100G/50G/25G/10G bit rates. The ethernet interface contains MAC + PHY layers. The
PHY layer is devided into PCS, PMA, PMD layers. A firmware, that executes in NIOS2 CPU,
will initialize the design , it will use AVMM bus interface for registers write/read. Management
layers also use AVMM interface only but not MDIO interface. PCS supports RS-FEC error
correction codes, 1/2/4/10-lanes. Data is distributed among multiple lanes at transmitter and re-
arranged at receiver. At regular interval of time alignment markers are inserter along with data
blocks on each lane. Each lane has its own PMA and corresponding PMD layers. The PMA
contains SERDES. PMD contains MDI interface and Auto-negotiation logic. The auto-
negotiation process sends a series of pulses with specific on/off period and as a series of bursts
of pulses. The pulses are data pulse followed by clock pulse.The data pulses represents the data
bits of a auto-negotiation capabilities register. The capabilities of an ethernet interface are
stored in multiple registers and are linked with next bit set. At the start of reset or at any time
based on request from management layers auto-negotiation will be done. The test bench use
synopsys ethernet VIP model for verification.

I involved in the following activities:

I made verification plan for auto-negotiation, identified testing scenarios, identified the test
bench adjustment requirements, but not implemented anything.

Intel WWID: 11389452, PSG-OPS group

Service company: Einfochips, Emo-ID 11001746 , Grade-B , PES division

Teradyne: Aug-2016 to jan-2017

Project Testing instrument HW design alarms & interrupts verification

Technology Testing equipment
Role Verification engineer
Tools & ncsim, Verilog, systemverilog, UVM.
language FPGA-Kintex7 series.
Team size 3

Synopsis
Teradyne company has an automated test equipment that is used to test other semiconductor IC
or components.The design of testing equipment is partitioned into two parts : 1)PCIE interface
part ( board-1 ) 2)ADC/DAC controller part ( board-2 ) FPGAs. No. of (3) ADC/DAC
 controllers present in board-2. No. of (8) board-2 type boards can be connected to board-1.
ADC/DAC are used to sample/drive the I/O pins of IC/component to be tested. Host computer
interact with design using PCIE-bus. DDRAM-3 is used to store the digital patterns to be
driven to DAC or to store the digital patterns that are recorded from ADC. Flash device is there
for permanent storage of patterns that will be used in testing. AXI-bus based interconnect and
DMA-engine are there to data write/read from host to DDR3 memory or from flash device to
host/DDR3-memory. There are many(24) alarms from each board-2 type boards , thus ( 8 x 24
) alarms will be reached to board-1.The alarms will be triggered as interrupts on PCIE bus as
MSI-TLP packets. Configuration & control register controls which alarms are to be reached to
board-1 from selected board-2 type boards. There are few(3) special alarms per each board-2
type , once they reach board-1 it will shutdown the data paths(channels) to board-2 type
boards.There are FPGA temperature sensors ADC , and ambient temperature sensor ADCs ,
power supply monitor ADCs.When ever over temperature or over power supply is detected,
then corresponding ADC digital data is monitored and shutdown will be supplied to all borad-2
type boards, it may also trigger an PCIE MSI TLP interrupt.

I involved in the following activities

• Test bench update ,
• Few (10) test cases coded,
• Few assertions coded
• Few functional coverage groups & cover properties coded.
• Filed few(10) bugs, &
• Analyzed code & functional coverage reports.
Service company : Einfochips, Emo-ID 11001746, Grade-B, PES division

RockWell Collins (RCI): May-2016 to jul-2016

Project Flight control system Test bench review

Technology Aero
Role Reviewer
Tools & DOORS, Modelsim, ncsim, Vivado, fpga-XQ7A100T
language Verilog, systemverilog, UVM.
Team size 1

Synopsis
One module of the flight control system is connected to a processor using PCIE bus. The PCIE
operates at 2.5Ghz, i.e. gen1. PCIE type0, type-1 configuration space is used for configuration
registers write/read. The module connects to processor using PCIE and connects to other two
modules. Module to module communication is 4 wire {clk, vld, eom, data} serial
communication links. There are 3 TX links and 5 RX links that are connected to two other
modules. The data is buffered in the all modules as frames/packets and will be forwarded other
modules. Three types of frames/packets are transferred, one type is for registers write/read,
other type is data buffering and another is for messages transfer. Error detection and correction
is provided. Frames are duplicated and transmitted in two different links with some randomly
chosen delay between transmission. Reliability in transmission and detect faults is important.
The project is executed as per DO-254 ( design assurance guide for airborne electronic
hardware(AEH) ).The work done need to documented such that at any time anyone can review
easily and easy to trace from requirement to final results forward and backward. Regular
review of project work including source code is to be done. Authorized agent need to be
certified the way of work done and quality of work and verification results.

• I reviewed three modules that are used in flight control system.

• For all three modules I reviewed the test plan and test cases as per requirements,
• Reviewed the source code of test bench and test cases
• Reported the issues found,
• Suggested better coding of SV
• Suggested better coding of UVM methodology.
 • Reported issues that violate DO-254 (design assurance guide for AES) standard
Service company : Einfochips , Emo-ID 11001746 , Grade-B , PES division

AVAGO/LSI: April-2015 to Dec-2015

Project Multi-core(16) cache coherent system SOC ACP verification

Technology Multicore SOC
Role Verification Engineer
Tools & VCS , DVE, nWave;
language System Verilog , ARM-ASM, FRM
Team size 1

Synopsis
It is a 4-clusters SOC where each cluster has 4 CPUs. Each cluster is CA53 64-bit cache
coherent 4xCPU based on ARM-V8 architecture. In its possible configuration the CHI-bus is
selected as coherent bus and corresponding CCN (cache coherent network) interconnect is used
for cache coherency maintenance. Each cluster has one ACP port which is basically an AXI-4
bus and the user signals has coherency meaning as defined in its architecture specification.
Multiple NIC40x interconnects, memories, and other IO slaves are present in SOC.
• Verified Data Path verification from ACP port of each cluster of CPUS to all memories
and IO devices in the SOC
• Verified coherent transactions, Secure-transactions, normal transactions
• Verified AXI-interconnects, CHI-interconnects data flow
• Developed a CHI-transactions monitor that display meaning of each field
• Suggested few techniques to speed up simulations
• Verified outstanding capabilities of CPU, CCN interconnect.
• Functional cover groups coded.
• Connectivity test coded to improve un-covered IO signals.
• Assembly code used in testing,
• FRM commands file used in testing.
Avago/Broadcom: NID - N6013388, [email protected]
Service company: Graphene Semiconductors, GSS-IN121, [email protected]

SanDisC/WesternDigital : jan-2015 to march-2015

Project Soft Error Detector (SED) Controller verification
Technology Storage SRAM
Role Verification Lead
Tools & IUS, IMC
language System Verilog, UVM
Team size 2
Synopsis
SED is a central control unit that detects bit errors, based on parity/ECC checking, of many memory
interfaces.CPU/other modules are doing write/read operations into an array of memories. An instance
interface module does actual initialization, detection of bit errors and reports to SED central
controller. An array of instance interfaces module, each connected to one memory interface, is
reporting to SEC-controller. The detected errors from any memory interface will reach a common
controller for further processing. one/two interrupts will be generated whenever an error is detected
based on configuration

• Architected UVM based generic/parameterizable verification environment for given

generic/parameterized design
• Developed UVM based verification environment
• Listed testing scenarios
• Coded 12/24 test cases. Each test can work on any parameterized design
configuration.
• Assigned 12 test cases to other team member to develop
 • Run regression of all tests
• Analyzed code and functional coverage
• Closed coverage with 100% code and 100% functional coverage with exclusion list of
signals & variables.
• 40-bit Synchronous counter is verified as IP module. Analyzed code & functional
coverage , closed with 100% with exclusion list of signals
SanDisc : 27726, [email protected], dept: 0506520016-CE ASIC
SOC
Service company: Graphene Semiconductors , GSS-IN121, [email protected]

BroadComm: march-2014 to dec-2014

Project ARM CPU CA53 based SOC verification
Technology UVM , UMVC, SystemC-TLM
Role Verification engineer
Tools & VCS, DVE, SGCANVAS , G++ , ARM-DS;
languages Systemverilog , SystemC ,
Team Size 1
Synopsis
The design is an ARM CPU based SOC with many IP cores integrated into it like pcie, usb,
Ethernet-phy, ddr, flash , sram , axi-interconnects, AXI, AHB and APB buses etc.

• Proved the concept that UVM-TLM and EVS(systemc)-TLM can exchange GPL
transactions. It helped to improved simulation speed by booting EVS system from a
memory with in EVS system and doing write/read into/from RTL IO devices.
• Verified SRAM memory controller IP module in the an SOC.
• Worked on GLS simulations of an SOC project

Client Broadcom: [email protected]

Service company: Graphene Semiconductors , GSS-IN121 ; Ref [email protected] , +91-
98453-88305

Rambus: Dec-2013 to March-2014

Project Test chip ,of Controller PHY of DDR memory ,Verification

Technology Storage DDR3, DDR4
Role Team Member
Tools & IUS
languages systemverilog, UVM
Team Size 1
Synopsis
Memory controller sends commands to CPHY using DFI-Interface. The CPHY translates DFI-
commands to DDR commands. CPHY just serialize 20/64-bits of DFI command/data into 10/8-bits of
command/data and supply to Memory. For characterization of CPHY it is embedded in a Test chip.
The test chip is accessible through JTAG interface. It contains a pattern generator. As per programmed
test vectors in the pattern generator it will generate stimulus to IO signals of CPHY. Thus a set of DFI
commands are supplied to CPHY and CPHY supply a set of DDR commands to memory.
• Developed 2 ASIC loop back tests and verified
• Developed 3 IO loop back tests and verified
• Four other tests developed and verified
Service company : Graphene Semiconductors , GSS-IN121 , [email protected]

HCL technologies: March-2012 to jan-2013

Project AeroSpace Controler , Ethernet Bonding verification
Technology Aerospace , ARINC429 , Ethernet
 Role Verification engineer
Tools & IUS, Modelsim
languages VHDL verilog , systemverilog
Team Size 1
Synopsis
Aerospace control system has a display, central processing system and multiple equipments. The
equipment’s are connected to sensors. The equipment communicates to central processing system using
32-bit labels baseband communication through ARINC 429 bus protocol. ARINC429 BUS uses a self-
clocking, self-synchronizing data bus protocol (TX and Rx are on separate ports).

Ethernet bonding is a process of dividing larger frames into smaller frames and combining smaller
frames into bigger frames. This design has four Ethernet ports at left side and four Ethernet ports at
right side. Each Ethernet port has a TX lines and Rx lines and are configurable to 100/1000 Mbps data
rate. A serial port to configure registers that will define the frame lengths and port credits etc.
parameters

•Involved in the verification of Aerospace controller as a part of 15 members team: writing few
tests cases, contributed to add new features to design.
• Involved in the verification of Ethernet bonding IP module as a part of 6 members. Writing few
tests , helping team on writing assertions & cover properties.
EMP-ID : 51415386, Department: ERS-OEM-DCS-VLSI

Intel Mobile communications: dec-2011 to jan-2012

Project ARM1176 CPU based SOC Virtual Prototype development
Technology Virtual Prototype
Role Verification engineer
Tools & CoMET , MeTeor
languages SystemC, TLM-2.2, c/asm
Team Size 1
synopsis
The complete ARM1176 CPU based SOC is to be developed as VIP only. The CPU and all other IP
cores also systemc-TLM models. The target is to speed up TLM simulation. Generic payload is
exchanged between system-TLM models. All models are coded based scheduling events and when
scheduled event is triggered the corresponding process executes. Thus systemc simulator is not doing any
work other time except the scheduled event of time. Thus simulation speed up achieved. The Global
quantum time is adjustable to tune speed versus accuracy control. The test cases are c/asm-based which
will run on arm1176 processor. IP modules verified using standalone systemc test bench. Integrated IP
cores verified by writing c/asm tests.

• Verified I2C systemc-TLM model

• verified Q-SPI systemc-TLM model
• Verified SafetyManagementUnit systemc-TLM model
• Verified SystemControlUnit systemc-TLM model
Intel WWID: 11735018, [email protected]
Service company : GlobalEdge, Emp-ID: 1267, Department : Infineon

LSI : dec-2010 to sep-2011

Project SAS target transport layer RTL verification
Technology Storage SAS
Role Verification Engineer
Tools & IUS, Vmanager ;
language s systemverilog , SV assertions
Team size 3
Synopsis
Serial SCSI (SAS) is a bus protocol that is used in disk drive systems and Solid state disks. It supports
multiple initiators and multiple targets and expanders. The target contains a Physical layer, Link layer
 and transport layer. The transport layer is responsible for command frames processing, sending response
frames etc.

• Plan and update of old verification environment as per latest design.

• Porting old c/c++ test cases as new systemverilog test cases
• New test cases development
• Debug and report issues in the design
• Adding new tests to improve coverage
Service company: GlobalEdge, Emp-ID : 1267, Department : Infineon

KPITcummins : April-2007 to July-2008

Project BlueSpec-SV evaluation, SystemC modeling
Technology EDA tool evaluation
Role Evaluation engineer
Tools & BlueSpec simulator, MSVC
languages BlueSpec-SV, systemc
Team Size 3

Synopsis
BlueSpec’s SystemVerilog is an ESL (Electronic System Level) Hardware Description Language that
can be used for Synthesis and Simulation using BlueSpec’s tools. The tool works based on terms
rewriting systems and the coding is rule based. A very complex hardware system can be described by a
set of rules and with the help of built in best hardware components. The high level synthesis tool
synthesizes best hardware that is correct by construction for the given set of rules. The data path is coded
by programmer and the tool inserts the control path circuit and clock and reset signals.

As per requirements in some other teams, systemc models are developed to ensure that the design can
work as proof of concept. No TLM used, only RTL equivalent systemc models developed.

• Evaluated BlueSpec-SV ESL language

• Developed a simple Programmable State Machine systemc model
• Developed KASUMI encryption/decryption engine systemc model
EMP-ID : KPIT-KP3771

Agere Systems: July-2006 to April-2007

Project Read channel RTL verification
Technology Storage SATA
Role Verification Engineer
Tools & IUS ;
languages systemverilog
Team Size 3

Synopsis
The read channel is a signal processing unit in the disk drive control system for the data storage. It
read/write the analog signal to/from the disk and processes the servo data and user data. Read channel
generally contains analog and/or digital filters, A/D & D/A converter, DPLL, synthesizers, thermal
asperity control unit, magneto asymmetry control unit, servo processing block, read data unit, write data
unit, quality control/monitor unit, serial interface for configuration, other interfaces for disk controller
etc. It is mixed (analog & digital) signal IC.

• Verified few test cases related to servo block

• written functional coverage groups and properties
• written assertions
Service company: KPIT-Cummins, Emp-Id : KP3771