Background: AVIPs let you emulate and verify a Design Under Test (DUT) on a custom hardware platform (such as the Cadence Palladium Z3), thereby reducing your testing times compared to regular simulations. You can read more about them here.
Writing a testbench requires us to connect the AVIP interfaces to the corresponding DUT interfaces along with the sideband signals (such as clocks and resets); and hence doing it by hand for large DUTs is error prone and leads to wasted hours in debugging.

My automation framework lets users easily create basic testbenches for large ARM designs with standard protocol interfaces, and allows them to configure specific AVIPs they would like to attach to the DUT.
My work reduced testbench setup time of higher core count designs of the ARM Neoverse Compute Subsystem (CSS) V3 from over a month to less than a week.
I also got a chance to work on cutting-edge technologies in the EDA industry while boosting my skills in tracing issues across the low-level stack: right from analysing waveforms at the nanosecond timescale up to debugging C programs running on the emulated ARM cores.

The primary languages and tech I used here were:

• Python, Make, bash, csh and tcl for automation,
• Verilog for the testbench and designs, and
• C for the firmware and test programs

Background: All complex systems, be it software or hardware, need to be tested extensively before being released. However, exhaustive testing of all combinations of system parameters is prohibitively expensive and time consuming, due to the simple reason that the number of test vectors grow exponentially with each new parameter added.

Keeping that aside for a moment, here are some resources which show that "all or nearly all failures (in systems) involve only 1 to 6 factors (or parameters)".

T-way combinatorial testing algorithms use the above assumptions to reduce the test vector sets by a significant amount while still covering all "t"-way combinations of parameters. Here is an interactive example for 3 boolean parameters:

A	B	C
0	0	0	<<<
0	0	1	<<<
0	1	1	<<<
1	0	0	<<<
1	0	1	<<<
0	1	0	<<<
1	1	0	<<<
1	1	1	<<<

< >

The exhaustive testcase array of three boolean parameters contains 8 entries, while all *pairwise* (2-way) combinations are covered with a total of just 4 entries. The IPOG strategy lets us generate such minimized coverage arrays for t-way interaction testing.

Given the parameter configuration (number of parameters, range and type of each parameter), the ACTS tool (which implements IPOG) can generate all 2-way to 6-way combinations in test sets. My work at TI was to enable auto-extraction and rule-based grouping of function parameter information from the C/C++ programs that interface with the embedded application, provide it to the ACTS tool and finally generate the coverage arrays that can be used for further testing.

Apart from working on testing, porting C programs with layers of abstraction and Python based automation gave me a chance to work with the ctypes library, which still comes in handy as I am learning eBPF toolkits and kernel programming.