Now you can access an FPGA LAB environment on demand with chiprentals. This service is currently in the Beta stage and is being provided for free. Go perform your projects in a real world environment. Book your slot here.

If you're preparing for an RTL or chip design interview, it's essential to be well-versed in the fundamental concepts and advanced techniques of digital design. This comprehensive guide covers all the topics you need to brush up on to ace the interview.

Most RTL interviews begin with some questions on digital design basics and then progress towards more advanced stuff or domain-related questions depending on the amount of experience you hold.

I’ve split the article into separate sections for beginners and the more experienced folks.

I’m not trying to give you a set of interview questions. There are lots of resources out there to find questions and answers. What I want to do instead is create an exhaustive set of topics that one needs to be on top of to kill it in an RTL or chip design interview.

Over time as I gave multiple interviews throughout my career. I have collected a good set of resources on the internet that I always refer to. I’ll share them alongside each subtopic.

Apart from general interview tips, if you are looking for tips and insights specific to an FPGA developer role in an High Frequency Trading firm, do read this article

BASICS

Sequential and combinational logic:

• Although questions this basic are usually seen only if you are an absolute fresher and are interviewing for your first job, everyone in the digital VLSI domain needs to be crystal clear about the basics of Flip-Flops, Latches, their internal structure, and the general ideas of sequential and combinational logic.

• One popular type of question here is how to build one type of gate using another.

  eg: Build an XOR gate using only NAND gates, how would you convert a mux into an inverter, etc.

• If it’s an FPGA role you are interviewing for, you might additionally be expected to know about how these elements are realized and distributed on the FPGA fabric and how they are connected together to form more complex logic.

Counters and clock dividers:

• Every digital design interview is bound to have some counters-related questions since they form the basis for a lot of tricky and mind-bending problems that the interviewer can use to judge your generic problem-solving skills.
• They could range from building simple UP/DOWN counters using Flops or you could be asked to write RTL for a weird divide by 3.5 frequency divider.
• Take a look at this excellent white paper where the author defines a methodology to think about frequency dividers of all sorts including non-integral ones. https://www.mikrocontroller.net/attachment/177198/ClockDividersMade_Easy.pdf

Language (Verilog, VHDL, SV)

• Once done with the fundamental elements of digital design, the interviewer may want to test your RTL skills in the HDL of your choice or the one used in their company. These should be easy enough to answer once you’ve used an HDL in a project or an industry setting.
• Most commonly, I’ve seen college students reveal their lack of practical experience with HDLs when they end up thinking about verilog code just like they would about C/python code. The primary skill required for a digital design role is to let go of the sequential programming paradigm and be able to think in terms of the Parallel world that digital logic exists in. This is essentially the reason we differentiate between HDLs and programming languages.
• Another common misconception that I’ve seen among the young is having only a bookish idea of what Verilog ‘reg’ or a ‘wire’ is. I usually ask them the following:

//what would the variable 'hold' synthesize into in the following (Verilog) code snippet?
reg hold;
always@(*)begin
	if(input1)
		hold <= 1'b1;
	else
		hold <= 'd0;
end

• Failing to answer this set of questions properly will most likely get you rejected.

Static Timing Analysis:

• Once the digital logic and coding aspects are done, the next important topic is static timing analysis. This mainly involves the definitions of Setup and hold requirements and how they affect design parameters like the clock frequency among other things. Several configurations can be made using the launch and capture flops with some combinational logic between them. Each configuration would have a different critical path and would require you to be able to analyze from scratch the setup equation and the hold equation for that setting. You should also have ideas as to what can be done if the STA on a certain path fails.
• I’ve found Timequest’s user guide by Intel to be one of the best resources that explain the concept of STA checks in a practical setting. For solutions to STA problems, you should easily find resources that explain ideas like pipelining, register duplication, de-congestion of logic etc.
• As a fresher, you might not be expected to have worked on STA directly but nevertheless, you should know the concept of what STA is, why it’s the standard way of verifying the timing viability of the design, and what you would if you were to encounter a relatively common case of STA failure. Questions on this topic can range from fairly simple to very complex but it all depends on the level of your experience. -Metastability: This topic forms the core of the issue that STA is trying to solve. It is of outmost importance for one to have a clear understanding of this topic to ace both STA and CDC. I've written this detailed article on metastability and its mitigation.

Clock Domain Crossing:

• Most designs these days, be it for FPGA or ASICs would definitely use involve multiple clock domains. Again, as a fresher, you might not be expected to have worked on CDC but you need to be aware of the fundamental problem of CDC and some common ways of solving it.
• A wide variety of methods are used to perform CDC and a lot of decisions on how to go about it depend on the requirements of the design and other constraints like how precious are the resources or how mission-critical is the application. Several questions can be formulated on CDC.
• Another important subset of questions that falls under the same category is about situations where you have two clocks that are synchronous to each other. Depending on the exact clock periods of these two clocks, a lot of situations could arise where you might or might not be required to use specialized CDC circuitry. You should be able to analyze all such possibilities.
• One excellent resource in this regard is this article I wrote to collect and curate all the great knowledge and resources on CDC on the internet. It also has some quiz questions that look very much like the ones you will be asked in an actual interview.

FIFO Design:

• Another design tool that is very commonly used in digital logic design is the good old FIFO. They can form the basis for several types of problems and are broadly divided into Synchronous and Asynchronous FIFOs.
• One of the most interesting sets of problems that involve FIFOs is based on how you would go about deciding the depth required for a certain FIFO based on other parameters of your design. This requires you to account for various aspects like the read and write clock frequencies, burst lengths of the two domains and sometimes even asymmetric bit-widths of the read and write sides to come up with a logical calculation of the minimum depth of the FIFO required. I found this particular document very useful for handling questions in this domain.
• Another rather obvious set of questions related to this topic would be about the design of an asynchronous FIFO. This is one of the favorites among basic interview questions since it engages a lot of CDC-related design aspects. One should definitely study the architecture of an async FIFO in detail. I once had an interviewer make me start from a simple double-flop synchronizer and keep adding layers to the problem ending up with a complete asynchronous FIFO of 0 depth, in order to losslessly transmit a sequence of pulses from the source domain to the destination domain. The entire train of thought required a very good understanding of what each element in an async fifo exists and what it does.
• I find this post on the Zipcpu blog to be a good go-to resource for async FIFOs. Ideally, you should be able to code an async FIFO from scratch if asked.

State Machines:

• State Machines are the most common building blocks of any kind of control logic that you may need to write and can range from a very simple pattern detector to a super complex logic that can approximate a CPU.
• In a theoretical setting, we divide state machine coding styles into Mealy and Moore styles. But in practice, there are several nuances to how you code up state machines and how it can affect your design parameters like maximum achievable frequency, resource utilization, power consumption, and also how easy or hard it would be to debug, edit or scale the code in the view of changing requirements.
• Although I haven’t found an exhaustive source that talks about all these aspects and will probably write one article on this topic, this white-paper by sunburst is very helpful.
• There is also a lot of nuance to how you would encode your states and I found this document useful for this discussion.

Resets:

• Resets can be an extremely important design consideration if you want to become a good engineer with the perspective to plan things at an architectural level.
• You’ll find a broad variety of opinions on the internet when it comes to the aspect of synchronous vs asynchronous resets and also the FPGA folks would have different opinions from the ASIC ones.
• For FPGAs, I find the Xilinx white-paper on resets to be helpful. I also like the sunburst paper on this topic as a good go-to resource.
• Apart from this, there is an entirely another involved aspect of this topic called Reset Domain Crossing (RDC). Badly done RDC can lead to metastability just like CDC. Today, meny companies perform RDC checks just as rigorously as CDC checks and you having an idea of the fundamental issues can be a great bonus.

Constraints:

• This is a topic that a fresher might not get asked about but is very important otherwise. Especially if you are an FPGA engineer, you would usually be expected to be able to add clocking, timing and maybe even placement constraints to your design apart from writing the RTL. CDC is one more aspect where writing the correct constraint becomes important to prevent hardware failure.
• I have found the book Constraining designs for Synthesis and Timing Analysis to be a gold standard reference on this topic.

Tools and Scripting languages:

• This is again a big one. As an engineer (of most kinds), you will be expected to be comfortable with using the tools of your trade.

• I’ll be listing down a list of commonly used tools separately for FPGAs and ASIC design but there’s lots of generic stuff that is expected out of everyone. It mostly consists of:

  • The Linux shell. If you’re going to be an engineer worth your salt. Move away from the GUI and be very comfortable with doing everything on the Linux terminal.
  • Make: make is a very rudimentary and extensively used tool that often ties things together in most toolchains. Let’s say you have like 10 different tools, each supporting 10 different commands that take 10 different options and inputs while being invoked. you cannot expect people to remember the commands. Make will give you a foolproof way to tie everything together and create repeatable, simple, and intuitive commands. Make will also keep track of all the files that are being passed to the tool/command and when any one of them changes, it will ‘make’ sure to re-compile the results.

  • Scripting Languages: On a daily basis, you will come across situations like having to parse large text files like logs and reports, documenting a long list of items from your code (like huge interfaces), generating raw data for simulation and testing or even writing proper code to test your hardware on the end-to-end system. For this, you’ll need to be well versed (or at least acquainted with if you’re a fresher) in one of the popular languages like Python, Perl, TCL, or sometimes even C++ in case you might be expected to write simple drivers on top of your hardware (this is very common too).

    • A lot of toolchains like that of Xilinx for example give you tickle consoles to automate the commands. So familiarity with TCL is usually expected after a point.
    • Perl is one very commonly used language. Most big firms have a lot of legacy tools and scripts like RTL generators written in Pearl. However, I personally hardly know Pearl and have never faced an issue handling it if needed.
    • Python is super powerful, easy to write and read and my go-to language to do anything arbitrary in a quick and easy way.
    • If you’re interviewing for an FPGA role, familiarity with C++ is also a very common ask. This is because an FPGA almost always goes into a bigger system that has a CPU talking to or controlling the FPGA. To efficiently do that and create complete systems to test on, you’ll need to write C++ based drivers.

  • FPGA toolchains:

    • Xilinx ecosystem:

      • Vivado for most of the things from simulation, synthesis, implementation, pushing bitstream to hardware etc. Familiarity with rarely used features like timing constraints wizard, manual floorplanning, IP packager etc may also be required for the more experienced folks.
      • Vitis/ Vivado - HLS: Despite its low adoption in the industry, HLS has garnered a lot of interest and people are actively putting it to the test.

    • Altera/Intel ecosystem:

      • Quartus for most of the things like simulation, synthesis, impementation, timing analysis etc.

    • Open source ecosystems:

      • The Ice-storm toolchain has come a long way and the hobbyist community is actively using it for many projects. It is however limited to the smaller Lattice FPGAs currently.

  • ASIC Tools:

    • ASICs require lots and lots of tools at each step on the way. Most companies use products by a certain vendor and religiously stick to that owing to the size of projects.
    • Simulation: Some of the most common ones are Synopsys VCS, DVE
    • Synthesis: Synopsys design compiler
    • STA: Synopsys Primetime, Cadence Tempus
    • CDC analysis: Synopsys Spyglass
    • Power analyis: Primepower, Powereplay, Mentor Powerpro

Advanced topics for the more experienced folks:

Protocols

• There are several domain-specific protocols that one might be expected to understand based on the job role. This could either be on the networking side (OTN, SDH, Ethernet, FC, etc.) Processor interface side (PCIe etc.) or a more generic interface format inside and SOC (AHB, APB, AXI, Wishbone, Arm Q, etc.). Low bandwidth peripheral interfaces like SPI, I2C, etc might be even more common for less experienced folks. Each would have its own nuances and specialties. It helps to have a generic mental model of all protocols (like the OSI stack model) even if you don’t know the specifics.

Valid Ready protocols and their complications

• Every sub-block in a big design that faces the network (irrespective of rx or tx) would have to implement some sort of a back pressure mechanism in order to deal with the variabilities and uncertainties of an actual network like congestion among other things. For this, chaining blocks sequentially using a valid-ready model is a very common practice. With this structure come a lot of nuances that can affect latency, performance, and even power. This is one good article by Zipcpu that talks about some of these issues.
• Skid Buffers: Skid Buffers are another common structure that you’d see in large designs with multiple blocks doing valid-ready handshakes with each other. Although the concept of skid buffers is simple. The primary aim of asking this question is to see if you have a sense of all the things that can usually go wrong with these interface mechanisms when you’re required to mess around with something in the handshaking path for application-specific reasons.

Arbiters

• Arbiters are another common occurrence. Whenever you have multiple events that can happen asynchronously (not as in asynchronous to the clock but completely independent of each other) you’ll need to come up with a mechanism to prioritize what you’re going to attend to. Also seen in scheduling problems of all kinds. I find this paper by Matt Weber to be a good primer for this topic. The main pain point in these structures can be scaling them to a larger number of inputs since they tend to be heavy in combinational logic.

Power Optimization

• Most designers never have the opportunity or need to think of power at least at an RTL level. If you’re an FPGA engineer it’s even less likely that you’ll ever face this problem unless you’re designing for a space or similar power-sensitive application. However at higher levels, especially in high-performance ASICs power is something that needs to be a primary concern as you might have seen while talking about which mobile SoC takes the lowest power and gives the best battery life. At the other end of the spectrum are large chips for networking, servers etc that can potentially consume kilowatts of power and need large cooling setups around them to solve this problem.
• Power optimizations can include many things like clock gating, voltage domains (running different parts of the logic at different voltages), or perhaps even RTL design implementation that reduce the number of redundant signal transitions. There is a chapter dedicated to this in the book Principles of VLSI RTL Design and it does an excellent job of introducing this aspect of design.

Computer Architecture

• This is another domain-specific topic that goes into the subject of designing a computing system. This used to be important mainly for the more experienced folks who end up working in teams that architect processors or things like AI related ASICS. With the explosion of the RISC-V ecosystem, these topics have once again come into the limelight since there are innumerable startups building specialized RISC-V products.
• It’s highly unlikely you’ll be asked about comp. arch unless the role or the company is in the business of building some kind of a processor (CPU,GPU, AI accelerator etc).

• A couple of resources that I can personally vouch for are

  1. The textbook by Hannesy and Patterson on beginner level Computer Organization concepts here

     2. The course "Digital Design and Computer Architecture" by Prof. Onur Mutlu at ETH Zurich here

  2. The course "Computer Architecture" by Prof. Onur Mutlu at ETH Zurich. This ia an advanced masters' level course and may not be required for everyone unless you're trying to land a very specific job in this domain. link

     4. This Playlist on yougube by Prof. Adi Teman about the different components of an SoC and a more direct application level perspective on the same concepts that we learn in the above two courses. link

Test planning and verification

• Although I will not go into the depths of this topics the idea here is that a design engineer should also be able to think of ways in which they can test their design. Constantly thinking about how to break your own design can make you a very good designer.
• One good way I practice this is by trying very hard to solve coding questions in a single try. It doesn’t matter if I’m doing an easy or hard problem. The primary goal is to be able to think of all corner cases in the first go and pass all the tests on the first try. This kind of thinking will improve the breadth of your thought and that is a very important skill in the world of digital design where the tools take so much time to run and iterations can become time sinks very soon.
• In a real job, as a designer you will be expected to directly contribute towards the verification effort by helping the verification team understand which testcases are more important than others and which ones are more representative of the real world usecase scenario. To answer these questions it is very helpful to inculcate this thinking into your thought process during the design stage itself.
• Another common question you might get asked in an interview is like let's say you just designed a block of logic, what are all the test hooks you would like to provide upfront so that in the verification stage someone validating your design can look for specific things. These test hooks can come in the form of status registers that are readable by software, or assertions that look out for conditions that are never supposed to happen or even processor interrupts that will eventually be synthesized to hardware in order to inform the system of an anomaly even during real world use and not just verification (you, the designer is expected to tell which one of these options you would choose and why based on the probability and seriousness of an anomaly happening with your design).
• You might also be asked questions that explore the options you have if the logic you designed gets stuck in some unwanted state due to a specific kind of input pattern (A hung state machine). Would you give a facility to reset that particular state machine? Or will one have to reset the entire top level design to recover? What is the cost of these operations on real world parameters like response time or lost information?
• Verification teams might also require the designer to signoff on the 'Coverage' they have achieved during the process of verifying your design. Coverage is a metric that tells to what extent the features in your design were excersised during the process of running tests. What if your forgot to add enough testcases? There would be features in the design for which the RTL was written but never got used. How would one know if it's working? This concept has a lot more varities and nuances however. I really liked this article on this topic.

Gearboxes

• gearboxes are simple yet interesting design problems that can be used to test someone’s understanding of how RTL translates to actual logic.
• A gearbox is used to convert the width of the datapath from one number to another due to a variety of reasons.
• Building a generic gearbox for any input width and any output width from scratch is a great exercise.

Production testing

• It is very common in an FPGA engineer’s job that the same person takes care of everything from design to actual testing on boards.
• Testing on boards can require a broad variety of skills like dealing with lab equipments like oscilloscopes, JTAG controllers, terminal based tools to bring up the board via the serial interface, writing C++ and shell scripts to automate repeated tasks.
• Some places may require you to write networking related logic like C++ scripts to build and send out packets in certain formats to another machine which has your FPGA running.

List of Resources:

• https://rajesh52.blogspot.com/?m=1
• Pipelining logic and complicated cases possible