Interview with Charles Fulks

Featured Engineer

Charles Fulks

Charles Fulks - Technical Lead, Intuitive Research and Technology

How did you get into electronics/ engineering and when did you start?

I got my start in electronics in the US Army. I enlisted after High School and was assigned to teach digital electronics for 3 years. I liked electronics and teaching, so I selected electrical engineering at the University of Central Florida. I completed a MSEE with a focus on signal processing immediately after finishing a BSEE.

What has been your favorite project?

I have been fortunate to work on many interesting projects; some quite successful, some cancelled. All have provided interesting technical challenges in many fields.

I periodically serve on teams assigned with finding a root cause of a large system failure. These are exercises in complete system analysis. While my primary expertise is in digital design and Field Programmable Gate Arrays (FPGA), most of these assignments draw on multiple disciplines such as analog electronics, RF propagation, physics, and chemistry. These are very rewarding assignments.

What are your favorite hardware tools that you use?

I use development kits from FPGA manufacturers such as Altera and Xilinx. These are invaluable in that they allow our software and FPGA teams to start integrating well in advance of receiving the project hardware. We regularly design models of the “outside world” that we include in the development kit FPGA design. This allows us to create real-world test scenarios for software integration. These techniques are always valuable in terms of schedule and product quality.

What are your favorite software tools that you use?

I use Hardware Description Language (HDL) simulators such as Mentor Graphics ModelSim and Aldec Active-HDL for functional simulation of our designs. These functional simulations generally have complex test benches that parse text files, instantiate bus functional models, etc. I have found that additional time spent during modeling and simulation is rewarded with few integration issues later in each project.

I regularly use The Mathworks Matlab and Simulink. I use these primarily to provide a flexible environment for modeling signal processing algorithms. I use these models to generate test vectors that are used in the HDL functional simulation.

I use FPGA manufacturer tools, such as Altera Quartus II and Xilinx ISE for FPGA synthesis.

One of my favorite tools is any revision control system. I have used IBM Rational ClearCase, Microsoft Visual SourceSafe, and others. These types of tools significantly reduce problems with teams working on different pieces of a design. The reduction of daily “which version of the file do you have” problems makes these tools extremely valuable.

What is the hardest/trickiest bug you have ever fixed?

Over the years I have worked on many interesting bugs. One that stands out is when our team that was faced with a critical embedded system that would completely erase its flash memory sometimes at power on. Statistically, this happened once in 200 power cycles. Circuit measurements and schematic analysis revealed a power-on reset (POR) circuit comprised of discrete parts that tracked the power rail until there was enough voltage to bias the base-emitter junction of a bipolar junction transistor. During the initial ramp, prior to POR low, there were approximately 10,000 clock cycles. Because other discrete inputs were indeterminate, this would sometimes signal the microprocessor that the next operation is a flash-erase. When POR was removed, the microprocessor dutifully continued the flash-erase operation. Removing the POR circuit and adding an POR integrated circuit corrected this problem. Although I did not design the “Rogue POR Circuit”, I learned to pay attention to every detail no matter how small.

Another interesting one was caused by obsolescence of a Texas Instruments 33 MHz ‘C30 DSP. The production group changed the bill of materials to use the new 40 MHz version of the part. The problem presented as spurious 1’s written to a memory instead of all 0’s, but only at cold temperatures. The root cause was that the new part was a 60 MHz part, with appropriately fast transition edges, that TI tested to 40 MHz and we installed on a printed circuit board designed for 33 MHz edge rates. The fast edges induced current in nearby traces; periodically enough to be registered as a 1. This was a great learning experience regarding high speed digital design.

What is on your bookshelf?

In no particular order…

Jack Ganssle, “The Art of Designing Embedded Systems” is full of design practices and philosophy geared toward creating higher quality embedded systems.
Dr. Howard Johnson has a fantastic book, “High Speed Digital Design: A Handbook of Black Magic”. Furthermore, I recommend his training seminar on the subject.
In “Peopleware”, DeMarco and Lister describe some surprising (or not) results of their survey of highly effective and highly ineffective companies.
Ashenden’s book “The Designer’s Guide to VHDL” is a definitive reference.
Richard Lyons has an effective, intuitive way of explaining complex ideas. His book “Understanding Digital Signal Processing” is one of the best on the subject.
Jean Labrosse “uC/OS-III The Real-Time Kernel” is an excellent RTOS book for product development, education, or reference.
Dr. Sklar’s book, “Digital Communications Fundamentals and Applications” provides a thorough and well thought-out treatment of the subject.
Ben Harding and RC Cofer cover almost all aspects of FPGA development in “Rapid system prototyping with FPGAs”.

Do you have any tricks up your sleeve?

Over the past two decades I have found that, for the most part, projects do not fail for technical reasons. Their success is mostly dependent on how well the team functions together. Fostering a productive environment is the first priority of a good leader.

I reserve for myself and my team the freedom to make mistakes. Most engineering mistakes during detailed development, assuming they are quickly identified, are not very costly in terms of schedule or budget. The lack of fear of negative personal consequences frees the innovative side of the engineering team. Quite often, this enables development of a much better product.

Do you have any note-worthy engineering experiences?

During preparation for an IEEE hardware competition in college, I learned that large rechargeable batteries can provide much more current than you expect. Subsequent lessons include: 1) reversing polarity on an op-amp IC will cause the die to leave the package, 2) silicon glows bright orange, and 3) glowing silicon will burn through denim blue jeans.

What are you currently working on?

Currently I am working on two projects. One involves high performance image processing in an FPGA. This customer needs complex algorithms in a small, low-power package.

The second project involves redesigning an existing system; primarily due to electronic component obsolescence, but also to incorporate new features. While this may not seem exciting, it is interesting to understand engineering decisions that were made a decade ago. Faced with limited computational resources, they devised innovative solutions that are sometimes applicable to “modern” problems.

What challenges do you foresee in our industry?

Digital design, as implemented in FPGAs, faces a challenge of growing complexity. Large FPGAs now have several hundred-thousand logic elements, with thousands of MACs and memories. Design teams must develop with a coherent process. This is similar to the state of software development in the early 1980s. I have seen too many teams start coding HDL almost immediately; substituting action for thought. Our team has used process appropriate to the task at hand with great effect at reducing debug and integration time.