Cirrus Logic Internship Experience

Abstact

Having minimal prior experience in the python language, driver implementation, and post-silicon validation, my growth and advancement as an electrical engineer at Cirrus Logic has been substantial. I worked in a team that developed a comprehensive post-silicon testing framework. In my eight months at Cirrus, I created various tools for our framework. Although, I primarily focused on creating drivers for lab instrumentation and corresponding documentation. This experience allowed for cultivation of technical skills alongside interpersonal skills as development often required collaborating with specialists on our team. My experience in the semiconductor industry has reinforced education from former classes and given insight towards selecting future ones. Overall, my 2022 co-op experience at Cirrus Logic has been a positive influence, maturing my professional standing in the fields of Electrical and Computer Engineering.

Introduction

During our undergraduate career at the University of Florida, we are advised and encouraged to pursue internships in our academic field. Internship opportunities provide insight in the selection of future classes, reinforces previous classroom education, and displays a glimpse of the various professional environments available after graduation. Prior to my senior year of university, I sought work experience to gain such wisdom. This brought me to Cirrus Logic in Austin, Texas, for an internship co-op taking place during the spring and summer of 2022. My term as an engineer in the Validation Technology team, later renamed Platform Development, brought understanding of post-silicon engineering and the semiconductor industry overall. While at Cirrus, I researched equipment, developed drivers, and created documentation on numerous lab instruments for use in our python testing environment. I also made automatic documentation tools and functioned as a support role. Implementing tests, applications, examples, and collaborating directly with end-user engineers comprised my support responsibilities.

Company Role and Responsibility

Project Overview

I worked closely with a senior engineer who created the driver library. From him, I was able to learn the style and best practices he had refined. When starting in January, my first assignments were clerical in nature. For the first week I was tasked with retrieving manual and data sheet documents and creating tickets for a backlog of desired instrument drivers. While time consuming, this gave a good understanding of the workflow tools that were used at Cirrus, Including Atlassian Jira, Confluence Docs, and Bitbucket for Git version control.

Senior engineers walked me through an existing driver to become acquainted with the Standard Commands for Programmable Instruments (SCPI) alongside the PyVISA communication python package. PyVISA is used to write and query commands over a given communication bus. Abstracting communication allows for multiple connections and various bus types such as ethernet, USB, or the primarily used IEEE 488.1 General Purpose Interface Bus (GPIB). Using PyVISA enabled communication of SCPI commands to a selection of bench instruments such as multimeters, power sources, and oscilloscopes. The actual instrument drivers I developed varied. The priority of driver development was based on upcoming testing requirements for silicon due to arrive.

On the surface, driver classes are created with instrument model attributes for PyVISA addressing and methods that either query the current state of the instrument or change the instrument’s state. However, some lab instruments require a detailed user experience due to instrument complexity or desired use case. To best mitigate complexity for the end-user engineer, input parameters were to be checked before communication and documentation of driver methods was to be precise. The sphinx documentation tool was used to collect method docstrings from source code and document the driver API. The structure of the desired output was shaped by customizing ReStructured Text files (RST). Our RST files were formatted not only to display relevant methods, but also images, notes, warnings, driver class inheritance, and links to pertinent documents such as manuals. Sphinx then allows generation of HTML documentation based on the RST files. This process streamlines the acquaintance of an engineer with a driver, with the ideal goal of the engineer never opening the manufacturer’s documentation.

Beginning Driver Implementation

My first tasks were to create drivers deemed simple or could be implemented through inheritance of other existing driver architecture. This way, I was able to understand the core concepts of pythonic programming, applications of Object-Oriented Programming (OOP), and creating an instrument driver for our library. I was given the task of creating driver functionality and error checking for a programmable resistance substitute This was followed with refactoring existing driver code for similar instrument models. Near the beginning of my internship, I had refactored drivers for a Keysight E36313 power supply and a Tektronix MSO5034 Oscilloscope. This introduction was productive in hindsight, yet also shed light on the discrepancies in SCPI support for lab equipment. Mainstream manufacturers such as Tektronix, Keithley, or Keysight may have hundreds of pages or entire manuals dedicated to programming an instrument. This is in stark contrast to documentation produced by manufacturers that prioritize in person functionality over remote use. This distinct perspective of instrument manufacturing produces instruments that may only have a few pages of SCPI support and documentation. Thankfully, support complications were minimal for my first few drivers. Later in my time at Cirrus, I implemented a driver for the Transmille 8104 digital multimeter. While the general implementation of a DMM is simple, the instrument proved cumbersome when communicating remotely. Often, I found the manual having blatant mistakes or omissions in the SCPI command documentation.

Textronix FCA3103 Frequency Counter

One of the most notable drivers I created was for the Tektronix FCA3103 Frequency Counter. For context, A frequency counter allows for high-resolution frequency measurements on one or multiple channels. In our use case, we desired to use the instrument to conduct a frequency wander test over a period of hours, days, or even weeks. Previously, a similar test was implemented using a LabView program designed by a validation engineer. However, the engineer was leaving Cirrus and I had a short window of opportunity to understand the desired application.

The frequency wander test was compromised of continuous zero-dead time measurements, sampling input frequencies as fast as 200us with verifiable times ¹. A fetch of data included the IEEE binary transfer header, which describes the amount of data being transferred in a single fetch. Each fetch was comprised of Header data, then a block consisting of sample data with alternating frequencies and timestamps. Data was to be continuously fetched over the GPIB communication bus for writing and appending the data to a binary file. Separate files stored header data and sample data. I created special file IO methods to complete directory and filename checking while abstracting the writing and appending processes for safe and efficient usage. The test was conducted in a multithreaded process that fetched data from the instrument and recorded the data as background task. Multithreading allowed for usage of the engineer’s computer while testing, and the ability to abort a test gracefully without compromising data streams. The test could also be configured to run for a time period given in seconds.

After the test was conducted, the files could be accessed on the engineer’s lab computer as binary data. Interpretation required decoding the binary data for displaying double precision floating point frequencies and 64-bit integer timestamps. A reading method was implemented to simplify this experience. Sample data was read into a list in memory using my file IO system and NumPy. NumPy was used for efficient parsing and Interpretation of the binary data. This created user friendly arrays for frequency values, timestamp values, and time deltas. Header data was also read at this step to return fetch buffer sizes as an array to verify continuity in the process. While this was a fast method overall, it could still take considerable time for voluminous amounts of data to be processed. Therefore, wait visualizers and progression bars were implemented to reassure the engineer the operation is ongoing. This was pertinent as running the test for a few days or weeks resulted in gigabytes of data. Originally, parsing data was slower before using NumPy tools and the reassurance was more significant.

A method for displaying decoded data using matplotlib was also developed. While not directly in the driver code for matplotlib dependency concerns, the data display method was added to instrument example documentation. This was used to visualize the frequency over time as well as density of frequency readings. Time deltas and the fetch buffer sizes were also graphed to show discrepancies or interruptions in the zero-dead time reading process. Such issues were found when sampling below 160us, but this barrier was attributed to the communication of data over GPIB and encountered with the LabView program as well.

Instrument functionality aside from the zero-dead time readings was also required for the driver after satisfying the instrument application requirements. This allowed the end user to create similar triggered events from the instrument measuring parameters aside from frequency, albeit with more configuration required. My workflow focused on being able to recreate the frequency wander test due to time constraints. This led to a backwards development as implementation of the instrument’s extensive functionality was added later in my progression. Due to the intense research into the instrument’s capabilities, I well understood how to implement all other functionality. I also refactored the test code to rely on higher level methods that were exposed to the engineer upon release so that even the test architecture could be used as an example for interaction with the instrument.

Keysight N6705C Modular Power Analyzer

The largest and most complex driver I Implemented was for the N6705 Modular Power Analyzer from Keysight. The desired application of the instrument involved synchronous actions of a power supply and electronic load. Voltage and Current measurements were desired simultaneously from the electronic load at a rate below 1ms using the instruments datalogger functionality ². For context, Keysight has a large lineup of modules ranging from power sources, source-measure units, and electronic loads. Modules could be loaded into the instrument by taking off the top or bottom of the chassis to reveal a total of four bays. Each module bay was associated with a channel on the base instrument. Some modules, including the supply and load I installed, may occupy two slots as a double wide module. Modularity and application constraints brought many challenges to the development of this instrument driver. Module sensing for dynamic channel creation, arbitrary waveform generation, and channel appropriate error checking on model abilities posed great opposition during development.

Channel sensing was accomplished by querying the instrument the model of each of the four channels. Based on the channel responses, communicating modules were queried for serial numbers, model options, and other metadata to be stored in a channel object. Based on the model of the module, type, voltage, current, power, and resistance ranges were assigned to the channel from a model dictionary. This dictionary was composed based on the dozens of models listed in N6700 family datasheet and stored in the channel object for dynamic attribute creation ². This composed an update channels method that would delete all current channels and create new channels using the queried data. By having channel metadata, comprehensive instrument implementation and error checking were streamlined. Channel parameter checks were reduced to comparisons between a model or option string provided by the channel object and unsupported models. Arbitrary waveform generation more tedious than challenging, as it required a comprehensive object-oriented structure. Primarily, this was due to support for sequences of waveforms, requiring multiple steps of configuration.

For the desired application, the internal and external datalogger systems were implemented for sample time experiments. The external system worked similarly to how the FCA3103 fetched data over GPIB, using the same File IO and plotting techniques. While familiar, this approach did not yield fast enough results for the tests required by the validation team. Therefore, the internal datalogger system was favored. This system performed the desired measurements at a sample rate of 40us and required exporting the data to external storage attached to the instrument. This data was saved as a CSV file, allowing for easy data interpretation using the same post-processing and plotting tools. Due to the instruments comprehensive functionality, I created documentation detailing both the internal and external datalogger systems and waveform generation.

Personal Reflection

As this was my first internship experience, it is important to review my professionalism, personal development, and career insight. My thoughts and growth can be summarized in the following.

Basic Skills and Professionalism

The skills that I exhibited during my session at Cirrus were that of a competent and capable gator engineer. My attire was orderly and appropriate for the work culture. Punctuality was pertinent as I made an active effort to be early and prepared for all meetings to the best of my ability. I reached out to others when problems rose that were beyond my control or understanding. My communications with coworkers were professional, respectful, and prompt.

Interpersonal Skills

While part of the Validation Technology team, I was able to exercise my public speaking skills in a relaxed environment. This helped immensely in my growth as explaining design choices and changes were necessary for team and administrative approval. Due to constant communication, my professional conversation skills saw remarkable improvement. The improvement in my interpersonal skills flowed well into my technical growth as well. I found myself liberal in asking questions, reaching competency in various fields faster. Relationships among peers became natural and assisting engineers with projects I worked on became second nature. Virtual communication methods were commonplace during my time at Cirrus, leading to a broader understanding of zoom etiquette. I was careful not to talk over others while also making my speech was clear and concise.

Technical Skills

Regarding my technical improvement, I have had the opportunity to gain experience my understanding in numerous concepts and applications. My knowledge of object-oriented programming and design concepts has expanded significantly. I have learned python and its various modules and packages from no python background and would consider myself proficient and adept in the language. Data interpretation, API documentation, multithreading, file IO, dynamic attributes, and time sensitive operations are all tools that I can implement successfully and proved during my tenure. I have had further experience implementing I2C and SPI communications with IC components. Cirrus has also introduced me to enterprise standard software such as LabView, Git, and PADs.

Preparation and Future Influence

In terms of being prepared for this internship, I would say that the curriculum of introductory computer science classes helped immensely in understanding design patterns and techniques valuable in learning a new programming language. Electrical engineering courses provided context to much of the applications of my responsibilities at Cirrus. While any software engineer could program a driver, understanding the use cases of an instrument or the functionality of an IC component on an evaluation board was pertinent to being successful in my role. This experience has also shaped my future course structure towards the semiconductor industry. Going forward I will be focusing on digital design, microelectronics, and overall computer engineering.

References

1. “Continuous measurements with zero deadtime,” Tektronix, May 2010. [Online]. Available: https://www.tek.com/en/documents/howguide/continuous-measurements-zero-deadtime-how-guide. [Accessed: 12-Jul-2022]. ↩︎

2. “N6700 modular power system family - keysight,” Keysight , 2022. [Online]. Available: https://www.keysight.com/us/en/assets/701805460/data-sheets/5992-1880.pdf. [Accessed: 13-Jul-2022]. ↩︎ ↩︎²