[go: up one dir, main page]
Scribd
Upload
2 views1 page

Explain Your Project

The project involves SoC-level verification of an automotive chip with multiple interconnected IP blocks, utilizing C-based test cases and SystemVerilog UVM for validation. The debugging process begins with analyzing simulation logs for errors, followed by waveform analysis using Verdi if issues are complex. The objective is to ensure correct connectivity and integration among IPs, addressing any identified issues in the testbench or RTL as necessary.

Uploaded by

Krishna Vamsi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
2 views1 page

Explain Your Project

The project involves SoC-level verification of an automotive chip with multiple interconnected IP blocks, utilizing C-based test cases and SystemVerilog UVM for validation. The debugging process begins with analyzing simulation logs for errors, followed by waveform analysis using Verdi if issues are complex. The objective is to ensure correct connectivity and integration among IPs, addressing any identified issues in the testbench or RTL as necessary.

Uploaded by

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

Explain your project

In my current project, I’m working on SoC-level verification of an automotive chip.


The SoC consists of multiple IP blocks — such as UART, SPI, DDR, and others — all
interconnected through a Network-on-Chip (NoC) fabric. The main master in the
system is a processor core, which is responsible for driving most of the
transactions and configurations."

"C-based testcases are used to program the processor, which in turn initiates
transactions to configure and control the slave blocks. On the verification side,
we use SystemVerilog UVM to build high-end checkers, monitors, and coverage
mechanisms to validate data integrity and protocol compliance at the interconnect
and IP interfaces."

"The core objective of the project is to verify the connectivity and integration
correctness between all these IPs at the SoC level. This includes checking the
routing paths, address decoding, access control, and proper functional interaction
among blocks via the NoC.

what is the debug flow?

When I debug testcases in my project, I follow a systematic approach that begins


with parsing the simulation logs. I first review the logs to analyze any errors,
warnings, or protocol violations — this often provides initial insights into the
failure. If the logs contain enough information to identify the root cause (such as
assertion failures, scoreboard mismatches, or timeout messages), I address the
issue directly based on the log trace."

"If the bug is more complex or not clearly explained by the logs, I move to
waveform analysis using Verdi. I use Verdi’s GUI and backtrace features to trace
the affected signal through the design hierarchy — starting from the output and
working backward toward the driver or control logic. This helps me determine
whether the issue lies within the testbench or the DUT."

"If it’s a testbench issue — like incorrect stimulus, timing mismatch, or a


coverage gap — I update the sequence, monitor, or scoreboard logic accordingly. But
if it’s traced back to the RTL (e.g., incorrect signal control, protocol
violation), I prepare a debug note with waveform snapshots and signal annotations,
and escalate it to the RTL team with a clear description of the failing scenario
and conditions

what are the testcases I debugged?

You might also like