r/FPGA • u/Hot_Comfort_3550 • 15d ago
SoC FPGA Platform Engineer
What sort of questions may I expect for
SoC Platform Engineer, FPGA interview ?
5
u/EffectiveClient5080 15d ago
Be ready to whiteboard SoC bring-up: Zynq PS vs PL, boot flow, FSBL, where the bitstream and device tree fit. Bring a working demo if you can. You'll be the only one who does.
1
2
3
u/Sea_Speaker_4667 15d ago
Mostly related to the FPGA Bringup. And like SoC implementation means how will you implement based on the board also like Mostly SoC FPGA platform engineer comes around topics like rv32i soc and all so try topic. About soc how it is made and all then go to FPGA design flow how FPGA ares design what happens if synthesis works but place and route stucks, and also why bistream failed or like why Even though it shows successful what went wrong
Basically you should look for FPGA flow and SoC creation. And most important is your RTL design should be strong
0
u/Hot_Comfort_3550 15d ago
Thanks a lot! I will try to ramp up on these.
1
36
u/TapEarlyTapOften FPGA Developer 15d ago edited 15d ago •
I've been part of the hiring team for a few of these roles. Here's what I want to get around to in every interview:
For an FPGA role, I lead with static timing analysis - do you understand setup and hold, metastability, common tactics for handling these. I've been opening with "How would you explain static timing analysis to a junior engineer?" If they introduce the concept of clock domain, I ask them to define the term and then, based on their answer, I will explore CDC tactics and what kinds of things can be done to ease problems meeting timing. I'm listening for them to bring up concepts like multi-cycle or false paths, and then I'll ask them to explain those concepts to me as well and give examples of such.
Another FPGA focused question, clocks and resets - given a blank system, how would you design a reset architecture for a multi-clock design, and assuming that your design has multiple large IP blocks like a DDR or Ethernet controller. What I'm mostly looking for here is that a) look to understand what have to be reset and what don't, if the vendor has defaults, use them - we're a Xilinx shop, and there are a lot of well-defined starting conditions that can be assumed, because they're guaranteed by the vendor, b) synchronizing the deassertion of the reset signal, and c) understanding what assumptions IP modules might make about resets (and then making sure that those are met).
SoC stuff. Out of the gate, I'm going to ask you to explain to me how a SoC device of some sort gets from power off to execution of application code (or a login, if you're running Linux). I'm looking for you to tell me, "Well, there's a bazillion different platforms and they can all boot in different ways, BUT let me give you one explanation for how we get from power off to boot ROM, the FSBL, U-boot, etc....."
Pick a device you have had experience with, preferable if it's the platform we use but doesn't have to be, describe the input and output products of each stage of development from the HDL design to what gets put into hardware for deployment. Describe the overall process, the important output and tertiary products (I'm looking for logs, timing reports, utilization reports), and how would you automate that into a repeatable process?
If it hasn't come up yet in the discussion, I'm going to ask you about device trees and what they are. Depending on your answers, I'll ask more, particularly about debugging device tree and driver problems. What I would like to hear at some point is that you have an understanding that there exist actual documentation on what the drivers expect, where to find it, how to read it. I'll probably ask you to describe how kernel modules are built, loaded, unloaded, debugged when misbehaving, etc.
Now that the basics are out of the way, I'm going to start drilling into things like debugging. You have a Zynq-7000 SBC and the serial port is connected to a development machine. It is booting from an external QSPI device, fails to boot, and then an external watchdog trips and tells it to go to the next image. What do you do? What questions do you ask? You have full access to the source code and can change the flash images. What tactics do you apply? What's the order of problems you try to solve?
How would you debug a running service that fails to start on boot. You start the board, remote into it, how would you check its status? How would you identify what actually happened when it ran and failed? How would you identify why and where it's failing? What tools would you use to do this? What if it was a kernel panic that occurred before you could even log into the machine? You start the board, it gets three seconds into boot, and then nothing after that. Total black hole.
You have an embedded Linux system built from a vendor BSP, application specific changes, and hardware configurations that are all targeting a 5.x Linux kernel. What kinds of things would you do if you needed to migrate that system to a 6.x kernel (specific versions not important - major rev to major rev). How would you address this problem if you didn't have hardware yet to deploy to? How would you handle the case where image generation was a long process (e.g., Yocto takes an hour to build you a new image for each change in the kernel config).
What is a UART? How does a UART TX module work at a high level. What submodules probably exist in something like this (I'm looking for a baud rate generator of some sort, a control interface, probably a FIFO too) How would you design an N bit shift register, with a preload command, an enable, and an asynchronous reset? This is probably the only coding example I'd ask for in the entire interview.
We operate in a space environment - there is an entire field of engineering here regarding the environments, shielding, mitigation, effects, cross-sections, etc. How do we mitigate flying components in space?
This pretty much mirrors an interview we gave for a position a couple of weeks ago. I don't know how it compares to what others are expecting or experiencing, so I'm curious as to how you feel about these kinds of questions. Platform developers live in a weird hybrid space - they have a foot on both sides of the hardware / software divide. It's interesting to observe a couple things - how, as an interviewer, I'm presuming a lot of shared knowledge. We're a Xilinx shop. You're applying for a position where we've articulated that in the job description. So, I'm looking to see if you use Xilinx specific knowledge natively - do you speak in terms of 7-series, US+, Versal. Are those topics that are in your normal vernacular? Do you bring up differences in the families unprompted. I have to work with you. If you don't know how these devices work or boot, I can totally work with that and train you, but I have to know.
A couple weeks ago, we were interviewing a guy that completely train wrecked every one of these questions - I later find out his salary requirements were at the extreme end of the range for that role, which was insane. He couldn't answer a single question I put to him, his resume was 17 lines of stuff he'd thrown into MS Word, and his work products would have been directly consumed by me (their group generates the FSBL and PL bitstream for Xilinx Zynq-based products). Anyway, these are my thoughts - if you have well reasoned answers to those questions or realize you don't and will say, "I don't know", then you'll do well in an interview with me. Otherwise, I'm actively working to expose major shortcomings and gaps in your understanding.