In this article, I will share the topics that are generally asked in a VLSI Design Engineer Interview. The topics will remain the same regardless of the design position you are interviewing for (RTL, SoC or ASIC). Speed is an important factor in an interview. The quicker and more confident you are in answering, the more chances you have of getting selected; and confidence & speed only comes with practice. Read the topics below carefully and practice everything before an interview, even if you believe you know all of it. Let’s start!
Questions from your resume:
Most interviews start with a brief introduction of yourself, in which you are expected to talk about the work that you have done till date. It is vital that you know each and every word written in your resume by heart. If you are not able to answer just a single question from your resume, it will not leave a good impression. If you only have half the knowledge about something, do not include it in your resume. I made this mistake just after my internship. I wrote fancy words like Lint, CDC, etc. in my resume, not knowing everything there is to know about those topics and boy oh boy was that a big mistake. I eventually got asked in one of the rounds if I had copied my resume from somewhere, that was not a good feeling. I somehow managed to overcome that image in the same interview, but everyone will not be that lucky. I have never made the same mistake again.
Sequential and Combinational Design:
You might feel you are confident in this area as it is Bachelors level stuff and might want to skip brushing it up. DO NOT DO IT! Questions from these topics generally get asked to recent college graduates, but you never know. You might get asked questions from these topics even after having 4-5 years of experience, and if you do, you must answer them correctly and quickly. Being experienced doesn’t mean you are to forget about the basic stuff. I am talking about questions like coding a simple MUX, a D flip-flop, a priority encoder, converting a MUX to XOR gate and stuff like that. I once got asked to optimize a+a’b; after having 3+ years of experience; in the interview round with a Director. I did it eventually, but after spending around 3 minutes on the solution, because I didn’t brush up. The answer shouldn’t have taken more than 30 seconds. It will take you only half an hour to revise these topics, but it can take you a long way.
Clock Dividers and Multipliers:
Yes, you read it right, Multipliers! Usually, no one expects a clock multiplier question in an interview because it isn’t used as it is in any design, but it is a very good question to check your logic designing capabilities and I learned it the hard way. I was asked to design a clock multiply-by-2 circuit in an interview. Stop and think for a minute. Do you know how to do it? If yes, good for you, if not, you should! I didn’t know the solution at the time I was asked, and I wasted a good 5-minute thinking about it. Try to solve this question on your own before Googling it up, the answer is really not that critical. Same goes for clock dividers. There is a good possibility that you will get asked this question. Divide by 2, 3, 4, all are really good questions, and you should be able to solve it within 5 minutes, with timing diagram and operation details. Practice it using a pen and a notebook before every interview. Draw the logic diagram, draw the timing diagram, write the code and try to walk yourself through the design. This will give you enough confidence should the question get asked in your interview.
Counters:
Counters are one of those resources which you will HAVE to use in one design or another. These are generally used to keep track of some event and trigger an action when the event has been done “x” number of times. There’s not much to it really, but you should understand the distinction between the counters used in Hardware Description Language (HDL) and the counters you would use in software coding languages like C++. For example, if you use a 2-bit counter, it will only count from 0 to 3. That is fine, but what if you must start counting from 0 every time the counter reaches 3? In C++, you would have to check when the counter value reaches 3, and when it does, you change the counter value to 0. In HDL, you don’t have to do that. The counter value will automatically reset to 0 in the next clock cycle when it overflows. You are saving at least a comparator and a MUX in this scenario. But beware of the subtleties. In HDL, the counter value is resetting to 0 only in the next clock cycle, should you want the counter value to not reach 3 at all, you will have to make extra adjustments.
Hardware Description Languages (HDLs):
Ah, the bread and butter of a VLSI Design Engineer... right? Not really! As a design engineer, you can go through your entire career without ever writing one line of RTL code, but you cannot go even a single day without seeing one. Your knowledge of HDLs is crucial as a design engineer. You will get asked at least one question around RTL, it can be either be a coding question or it can be a question about finding errors or issues in RTL code. The moment you start thinking about the RTL code in the lines of a software coding language like C++, you are done! You cannot blindly convert codes written in C++ or Python to an HDL like SystemVerilog or VHDL. HDLs just do not work that way. How would you know all this? Practice. You must practice lots and lots of RTL coding questions before appearing for an interview. You might look at an RTL code and think; Hmm... it is easy enough; I will be able to code it in the interview. DO NOT RISK IT! Look at the question, come up with the architecture on your own and then code it on your own. You should use the provided solution only to tally your solution or to know of a separate way to implement the solution. There can be multiple ways to code the RTL for a given module. Which solution you would use depends on several factors like timing, area, power etc. Let us try to understand a little bit more about it.
Synthesis:
You cannot code RTL effectively without learning synthesis and that’s what every interviewer expects from you. You don’t need to know everything about synthesis, but you should know what your code will synthesize into. The interviewer will surely ask that about your code, and they might also ask you to optimize the code for less area or less power or both. For example, if you are using nested if-else in your code, the interviewer might ask what will happen if instead of nested if-else, you used case statement. You should be prepared for these type of questions too.
Timing:
Same goes for timing concepts. You cannot be an effective RTL coder if you are not aware of the timing concepts. Interviewer might give you a situation where timing is not meeting and ask you to modify the design such that it meets timing. To tackle questions like these, you need not learn every aspect of timing, but basics like setup and hold time, critical path, etc. are enough. You should understand what it means when we say a design is not meeting timing, what is meant by breaking a timing path, common ways to resolve setup and hold time issues etc.
State Machines:
There is a 90% chance of getting asked to design and code a state machine as per my experience. State machines are an important part of hardware design. It has the ability to make complicated designs easy. We use state machines when more than one condition must be satisfied to trigger an event. Try doing a coding exercise where you have to drive the output high whenever you see 1010 in input in the last 4 clock cycles using two methods. One using only if-else statements, and another using state machines. See for yourself which one was easy. You can expect a normal sequence detector question, or more advanced questions like elevator operation or vending machine operation question, depending on the position and the company you are interviewing for.
Clock Domain Crossing (CDC):
There is a 100% chance of getting asked about CDC in your interview. Never have I ever been in an interview where I did not get asked at least one question regarding CDC. It is a very important topic, and it helps interviewers understand your digital design capabilities. It is kind of a gift for the interviewees as they tend to be very easy if you take your time to learn it, but it can get very complicated very fast and it becomes more curse than a gift in those situations. It all comes down to you. If you are very good at basics, it shouldn’t be much trouble, but if there’s even a small crack in your understanding, your whole knowledge wall will come falling in no time. That is why interviewers love this topic. YOU CANNOT AFFORD TO SKIP THIS TOPIC. It's as simple as that.
FIFO:
From the design interview point of view, there are two aspects to a FIFO – design and depth. FIFO Depth calculation is very easy. You can easily learn it in half an hour if you are good at math. On the other hand, FIFO design can get as complicated as you like; and I mean really complicated, especially the asynchronous FIFO. Nevertheless, you should at least know the difference between synchronous and asynchronous FIFO, how empty and full conditions are generated in both the FIFOs and a few more things which I will cover in a separate article.
Resets and RDC:
Resets are an important part of hardware design. We already know there are two kinds of reset – synchronous and asynchronous. When provided with a situation, you should know which reset to use with proper reasoning. There is no clear winner here, both have their advantages and disadvantages, and both are suited for different applications.
This is a perfect segue to RDC, which arises when using asynchronous resets, and has its own set of challenges just like CDC. We should know the hazards related to RDC and ways to fix them to at least have a small conversation with the interviewer about resets.
Arbiters:
Arbiters have increasingly become a favorite topic to ask for the interviewers because they are present in every design and can be easily coded in a 45-minute interview, if the interviewee knows their way around it. It is not very hard but not easy also. It is a perfect question to check logic design knowledge and RTL coding knowledge in a single question. Understand the difference between fixed priority and round-robin arbiters, their advantages and disadvantages, their equivalent hardware diagrams and their RTL code. This should be enough to prepare you for any kind of questions on this topic.
Ready-Valid protocol and its timing issue:
This is kind of a very specific topic, but I must add it to the list because they have been asked one too many times. Ready-Valid protocols are used widely for data transfers and are not very hard to understand. The complications arise when the ready path is not meeting timing due to whatever reasons, and we must fix it. Due to the protocol specifications, we cannot use standard methods to fix the timing along the ready path. We use something called a Skid Buffer or a Carloni Buffer. You must understand why we cannot use standard techniques for fixing timing and how a skid buffer helps in fixing the timing. You might also get asked to code the skid buffer and I must say that if you understand how skid buffer works, it is not very hard to code it. I must also add that if you have not practiced it beforehand, you will not be able to code it in the restricted time of the interview. So, it’s better to practice it before appearing for the interview. Recent college graduates can skip this if they want, but it’s nothing you won’t understand, so it’s completely up to you.
Scripting Languages:
Scripting languages are widely used in the VLSI industry, and it gives you an upper hand if you know any scripting languages, like Python, Perl, Shell scripting etc. Companies have started adding scripting language as a requirement in their Job Description, so it’s worth spending time to learn it.
Computer Architecture:
This might not be required for all design interviews. You can skip this if you are not interviewing for a position related to CPU or Cache design. But if you know the basics of computer architecture, it will help you code your RTL better. Understanding computer architecture helps you visualize the equivalent hardware of RTL code you have written and in turn makes you a better RTL coder.
Verification Knowledge:
It is vital that you know how to verify your design. You are not expected to know UVM/OVM, but you should be able to help the verification team in creating a test plan. You can be asked simple questions like how you would verify a synchronous FIFO and basically, you have to try to break your design. Think of all the normal and all the odd situations, and your design should perform as expected in all those situations. Thinking of corner cases for your design is the key to verifying it, and interviewers are literally waiting for you to mention at least one corner case.
Learn from your mistakes:
It is ok to be unable to answer all questions in an interview, but it is absolutely not ok to be unable to answer the same questions in another interview. DO NOT MAKE THE SAME MISTAKE TWICE! I believe everyone would agree that this saying holds for any kind of life situation. So next time you have an interview, write down the questions you got asked in a safe place, re-visit the answer you provided, and think if a better answer is possible, and of course you should take Google’s help to know of all the possibilities. Revise the questions and solutions before the next interview and you can be sure that you are indeed learning from your mistakes.
That is all I would like to add to the list of topics; for now ;)
Interview patterns are changing very fast, and it is highly dependent on the companies you are interviewing for. It will help you if you research the interview pattern for a specific company before appearing for the interview. Some companies like to delve more into your experience while others don't care about it.
Lastly, it all comes down to you. Interviews are not easy, especially now-a-days, and your success depends on how you prepare for it. I truly believe in the proverb:
Practice makes a man perfect
And that's the advice I give to everyone for preparing for any kind of interview.