Part 1 - What's the Problem?
I work for a semiconductor firm specializing in designing high-performance signal processing chips. For a typical chip, the inputs are real-world analog signals, such as electromagnetic waves, and the outputs are digital bit streams, organized in a specific format and typically transmitted at high speed.
I spend a significant amount of my time hiring design evaluation engineers for my team. A design evaluation engineer is responsible for chip evaluation and characterization in a lab environment. This involves developing and automating tests, collecting and analyzing data, and ultimately determining if the chip meets customer specifications. Given the diversity of tasks and complexity of the technology stack, hiring can be quite challenging.
Several factors must be considered when hiring full-time engineers, including hard skills technical skills, soft skills, and other intangible skills. While this article focuses on technical skills, it's important to note that they are not the only factor.
Part 2 - A Detailed Look at a Typical Daily Task
Let’s examine a design evaluation engineer’s bench setup, as shown in Figure 1. At the center of the setup, the chip sits in a socket on an evaluation board specifically designed for the chip under test. The board interfaces with all the chip’s I/Os and connects to various lab equipment. This equipment can serve as the source of input signals, like a signal generator, or capture the chip’s output, like a spectrum analyzer. An FPGA board is versatile, handling tasks like converting time-domain digitized signals to frequency domain via Fast Fourier Transform at high speed, and facilitating serial communication protocols such as SPI or I2C.
The host PC ties everything together, running test code that controls the entire setup. It issues commands to automate all test equipment, makes API calls to the FPGA, which then translates these calls into register-level commands, and controls the chip via low-level interfaces like SPI. The host PC also receives captured and pre-processed data from the FPGA, renders, and displays it. You can use various tools to write your test code, with Python and LabVIEW being popular options.
Part 3 - Areas of Interest
Imagine writing a test in Python. You apply an incident wave from the signal generator, send it to the evaluation board, which carries the signal to the chip's input pin. The chip processes the signal, converts it to digital bit streams, and sends it to the FPGA. The FPGA processes the data and sends it to the host PC, which then plots it on the screen. If the output is unexpected or an error occurs, how would you approach debugging?
The challenge is that multiple technology layers are involved, each requiring specific domain expertise.
3.1 Is it the Chip?
Is the chip the root cause of the issue? How can I ensure the chip is configured properly? Can I verify it with an internal test or by probing internal signals routed to the pins?
Signal chains on state-of-the-art chips offer antenna-to-bits conversion. Figure 2 below shows the analog portion of a typical signal chain. For example, the receiver path consists of a low noise amplifier (LNA), a mixer, a small signal amplifier, a baseband filter, and an analog-to-digital converter (ADC). Note this is a high-level abstraction; many more blocks are involved, such as a phase-locked loop supplying the mixer with a local oscillator (LO) frequency and low-dropout regulators (LDOs) powering internal circuit blocks. Massive digital circuits follow the ADC stage to manipulate digitized data, such as digital filtering and decimation.
Any block in this signal chain can cause the error. How much knowledge should I expect a junior engineer or a recent graduate to have on each block? It’s unrealistic to expect in-depth knowledge on all blocks from recent graduates. However, I design interview questions to assess their ability to develop the skills needed to debug complex signal chains.
3.2 Is it the Board?
Numerous board-level components form the signal path from the input connector to the chip input. Any defective component can compromise the signal integrity to the chip. If the chip input is outside the norm, the chip output can be unpredictable.
3.3 Is it the Software?
Software plays a crucial role in semiconductor products, especially with the emergence of software-defined products in various applications, including automotive, communications, industrial automation, and aerospace. These products can be reprogrammed to operate differently, a capability enabled by advancements in semiconductor processes, circuit design, and software development.
Reconfiguration is not easy, especially without jeopardizing performance. At a low level, numerous instructions must be sent to the chip via a serial interface (like SPI) even for simple tasks like powering up the chip. These instructions are dynamic, interactive, and non-deterministic:
- Dynamic: Operation changes with the environment, warranting different instructions from the host PC.
- Interactive: The next instruction depends on feedback from the chip.
- Non-deterministic: The sequence of instructions changes each time, preventing hard coding.
To streamline the user experience, engineers provide APIs to abstract low-level complexity, shifting the burden of dealing with complexity from customers to internal engineers. When a test error occurs and is traced to software, determining whether the bug is in the API software, firmware, or test code can be tricky. API, firmware, and test developers typically have distinct technical skill sets.
- API Developers: Work in a purely software domain without needing knowledge of the underlying hardware.
- Firmware Engineers: Design algorithms to run on chips and implement them in firmware code, typically in C, with in-depth knowledge of low-level circuit blocks.
- Design Evaluation Engineers: Write test code in a scripting language, such as Python, to develop and automate tests. Their exposure to software is broader, needing to issue API function calls that exercise firmware routines on the chip. Although they don’t develop firmware or API, they need to debug, identify, and report issues within them.
3.4 System Challenge
Viewing the chip as a system rather than a collection of circuit blocks can save debug time. However, knowing when to think in terms of a system and when to focus on individual components is an art that takes time to develop. There’s no shortcut to this intuition; it requires knowing when to “zoom in” and when to “zoom out.”
Part 4 - My Approach
While I’m not an expert in hiring, I’d like to share a few of my approaches and exchange ideas with the engineering community.
Regarding the circuit blocks covered in Part 3.1, it’s unreasonable to expect early-career electrical engineers to have deep knowledge of many blocks. However, if a candidate understands one block well, they can likely learn the others with the necessary resources.
Board-level knowledge is tricky. Engineers learn a lot about PCBs through designing schematics, layouts, and debugging components. PCB work involves meticulous attention to detail and experience, which junior candidates often lack. I ask qualitative questions to gauge a candidate's intuition about how electrons work in circuits. For example, I might ask how changing the width or length of a PCB trace affects impedance.
On software skills, there is a significant difference between a software engineer and a design evaluation engineer. The key is finding candidates with the right amount of programming skills. While software is crucial, it's only one piece of the puzzle. I’ve found that many candidates with electrical engineering backgrounds struggle with basic programming problems. This may be due to a lack of preparation for programming questions in hardware job interviews. Programming skills have a lower barrier to entry and can be developed over time, unlike signal processing or circuit design knowledge, which are harder to train and require extensive resources. This is why I am biased to skills such as circuit design, digital logic, and signal processing. If a candidate appears to be a bit weak on programming, my team can train and develop their programming skills over time. However, if they do not know some of the basics in signal processing or circuit design or digital logic, it would take a much longer time to train them.
References
[1] Source: ResearchGate
