A lot of topics were covered: async fifo, subtlety in asyn fifo timing, grey code counter, async reset, some design tricks, gate and latch timing and timing improvement technique, writing RTL code to design a block based on spec given, recursion scripting to solve an issue, linked list, domain crossing general issues, pipelining, etc. There were also a few IQ testing questions. After I detected the answers in time, I was requested to implement them in digital circuit. At the end of a session, the interviewer half-jokingly said, "Welcome to apple". Another interviewer said a few times I was doing well. Another interviewer assured me working there was not as busy as what people believed. Overall, I felt the atmosphere was casual, difficulty level was average and comfortable. BTW, most of the questions were NOT those standard ones found online. Instead, they tend to be unique, more complicated, and arising from personal experience of the interviewers (as they told me in the interview). Fortunately, I either encountered most them myself in my past experience, or was able to come up with the solution in the interview. Here are a few of them. - async fifo: the time for a write pointer to increment, to be synchronized to read domain, and to cause the read pointer to increment and synchronized back to write domain. What's the minimum depth of the fifo. - async fifo: timing constraint on write/read pointer (even though false path) so that it won't be sampled wrong in the other domain. - async fifo: timing issue on the path (false path) from read pointer, to data selection, to a read domain flop. (This is a question I benefited from the interviewer). - async fifo: how to avoid an extra clock of delay when using grey counter. (My method was to keep another copy using regular counter. The interviewer said he didn't think of this method before.) - async reset vs. sync reset. Async reset timing analysis. - If a fifo's write cycles are pipelined, how to avoid overflow. (my answer was to use conservative full signal, which the interviewer agreed.) - how to pipeline cycles (using fifo) on a bus to achieve a desired behavior. - how to use a latch to solve big hold time violation (use low-open latch). - timing path that crosses power domain through a level shifter. - write a script to traverse a tree structure. (I used recursion, and the interviewer confirmed that was the method he used too.) - Given a small RTL design, detect flaws in them. (reset was missing; domain-crossing interface needs to make sure number of pulses is preserved after domain crossing.) - how to use fifo in a tricky way to realize a given function (such as widening the fifo). - use double pointer in a design to solve certain challenge. (The interviewer confirmed my answer was what he used.) - read a waveform and discover the relation between the input and output signal. (At first it looked tricky. Then soon I found the relation. It involved edge detection, delaying a few cycles, xor.) - design a block that has control signals, a few inputs, and expected outputs behavior (though this task is straightforward once understood, it is time consuming in the interview and creates pressure. I was reminded I made a few typos in my code.) - implement a fifo whose depth is not power of 2. - sequence detector (only this one is a standard question). - elastic buffer, de-skew buffer, re-ordering buffer knowledge (as I had little prior knowledge of them, I had some time in the interview to think about them and interacted with interviewer. It's all based on common sense).