Interview Question 13: Random Number Generation

Random numbers are needed in verification to exercise various corner cases in a test benches. Every test bench is unique. Every test scenario calls for the different kinds of random number generation. Here are two common scenarios encountered in verification. The later question helps is constrained random verification.

- Create a function (or task / module) to generate 256 “unique” random numbers.
  The generated number is unsigned 8 bit number. A simple $random call may generate repeated numbers. Your task is to create a function which guarantees unique numbers in first set of 256 numbers. The next batch may repeat the whole set.

- Design a module which generates weighted random (pseudo random) numbers. Instead of generating unique numbers this time your task is to generate a small set of numbers randomly distributed but with agreed weight-age  Out of all 100 numbers generated the distribution of numbers should be as follows.

Numbers	Distribution
0	5%
7	20%
35	25%
145	30%
244	20%
Total	100%

Interview Question 12: Design a Garage door opener

Just like the previous question this one also deals with finding out a person's problem solving approach. 

A garage door opener is a controller which responds to multiple switch/sensor inputs and produces output for a motor to pull garage door up or down or stop in the middle. 

Half the fun in solving this design problem is in understanding the functionality and creating a list of conditions/specifications.

Interview Question 11: Design a beverage dispenser machine

This is a common question in many interviews for design positions. The expected answers vary based on experience of the person. A fresh college graduate may focus on just a state machine diagram design. An experienced person's answer will be very different. State machine diagram is just a small part of it. In any case this open ended question tests how a person thinks and approaches problem solving.

The articles I read - 1: Xcell Journals from Xilinx

I read my first XCell Journal in 1996 when I started working with XC4000 family of devices. It is a wonderful archive of tips on FPGA/CPLD devices. All the past issues since 1988 are archived online here.
http://www.xilinx.com/publications/xcellonline/ 

Click on "Past Issues" tab to access old issues. Let me know if you find any interesting read.

Interview Question 10: Trouble-Free Switching Between Clocks

How do you gracefully switch between 2 asynchronous clocks?

Here is an answer from http://www.xilinx.com/publications/archives/xcell/Xcell24.pdf

Asynchronously selecting between two clock sources can easily produce glitches that cause unreliable system behavior. The circuit diagrammed here avoids these problems.

While the SELECT input is stable (either High or Low), the two control flip-flops are in opposite states and one of the two clock inputs drives the clock output. When the SELECT input changes, there is no immediate impact until after the next falling edge of the originally-selected clock source, which also resets its control flip-flop. The Output Clock signal will then stay Low until the next falling edge of the newly-selected clock. This edge will set its control flip-flop, causing this clock to drive the Output Clock. Thus, with this circuit, any switching between clock sources is delayed by holding the output Low from the time the first clock goes Low until the time the second clock is Low.

Interview Question 9: Logic to find out number of data chunks

In one of my past back-plane design I implemented a store and forward logic. The packet data was sent in chunks of 64 bytes. One chunks consisted of 62 byte of payload and 2 bytes of data which contained other useful information like pointers to other chunks, actual payload bytes in that chunk, and QOS related tags.

Can you design a smallest logic to find out the number of chunks needed for supplied packet payload?

Interview Question 8: Sneaking CPU read/writes when continuous Memory Read Writes are going on

With the advent of increased performance needs new design challenges arise. This questions deals with one of such problem. A single port memory is continuously accessed by surrounding data plane blocks. They are accessing memory in continuous fashion. For example W-R-W-R.... There is no empty clock cycle to waste. 

The software wants to access this memory through CPU read/writes intermittently. Usually a simple mechanism using a state machine can be used to sneak in CPU access when no data plane access is going on. The problem arises when when this request gets timed out as every clock is being used by data planes accesses. How does one resolve this problem?

Changing single port memory to dual port memory seems to be easy solution but what if it is prohibitively expensive and not allowed. As design geometries are also stretched to the limit, increasing/doubling clock rate of memory is also ruled out.

How will you approach this practical problem?