I wrote a list of 10 things programmers must know. I felt it was unfair to leave out the hardware guys. Since I have already covered what the hardware designers need to know about software (here here and here), I am now posting some important review topics for hardware designers. Make sure you revise these topics before job interviews. While this list targets architects and VLSI/RTL designers, it is a good resource for anyone looking to brush up their understanding of hardware design. It can also be used as a study guide to learn hardware on your own. I purposefully use keywords that can be googled.
1. Understand transistors. You should be able to design a NAND out of transistors any given day. Don’t forget pass gates and the difference between N-P transistors.
(a) Why is the P-type (not the N-type) connected to the VDD?
(b) Design a 2-input mux using N- and P- type transistors.
2. Understand logic design. You should know truth tables, Karnaugh maps, and common units like the mux.
(a) Design a 2-input AND using 2-input muxes as your ONLY building block.
(b) Now try an XOR.
3. Understand propagation delays. Know the concept of gate delays and also learn techniques like tree logic used to reduce critical path.
(a) Why is a 32-bit ADD slower than an AND operation?
(b) Design a fast 32-bit comparator which does not require an adder/subtractor unit.
4. Know thy arithmetic.
Question: Design an 8-bit 2′s complement subtractor using ALUs and basic logic.
Note: For floating point, I doubt anyone will will ask you to design the circuit for an FP Multiply on the fly but you must know the basics well.
Question: What does the bit string 0110101 represent in an in-house FP notation where Most-significant bit is sign bit, the next three bits are exponent with a bias of 3, and the least significant three bits are the mantissa. For the unspecified details, you can assume that it follows IEEE FP standards.
6. Understand latches and flip-flops. You should at least know JK latches and D-flip flops. Be familiar with terms like edge-trigerred, level-sensitive, set, reset, Q, and Q-bar.
(a) Make a reset latch out of a set latch. You cannot change the internals of the set latch but you can use basic logic gates.
(b) Design the internals of an SR or JK latch using basic logic gates (AND, OR, NOT).
7. Know timing analysis. You should be on top of setup times, hold times, and critical path analysis. Remember what Clock to Q, and DQ delays are.
(a) Be prepared to do timing analysis of a circuit and calculate setup and hold time violations.
(b) Why are hold time violations worse than setup time violations?
8. Know state machines. Remember the difference between mealy and more machines.
Question. Design a clock divider which outputs a signal 1/2 the frequency of the input clock with a 75% duty cycle? Watch out for glitches due to uneven delay in gates.
Note: If you don’t understand what I mean by glitches, please read about grey code in state machines. Feel free to ask and I will explain it in depth.
9. Know scripting. Scripting skills can make you much more productive.
Question. How will you replace a variable name “FOO” with “BAR” in all files spread across multiple directories? You can write code in Perl, Python, or any other scripting language of your choice.
10-Circuit designers: Know RTL.
Question. Write the code for a 2-read port 1-write port register file in Verilog/VHDL. Each register is 4 bits.
10-Know Simulators: Know architecture concepts down cold. You can use this list as a very basic guide but I always expect architecture interviewees to know these items in great depth. Additionally, know C simulators really well. Details of how to write architecture simulators cannot be covered in a single question so I plan to do a whole post on this soon, stay tuned.
KNOW YOUR RESUME This is a general tip. An interviewer expects you to know everything you have written in your resume. Take out the stuff that you have forgotten or have not yet learned.
This concludes my top ten. Feedback, comments? Do you have stories to share from interviews?