The Next Generation of Programmable Logic Developer

Once upon a time, before the age of logic synthesis, an engineer might have been asked to design a system that was pure logic. This was when we had radar but no microcontrollers, and digital signal processing but no off-the-shelf digital signal processors. Nonetheless, we had digitally processed radar.

Back then, a newly graduated engineer was expected to know how to design analog and digital hardware and how to develop software. I fear the time of the broad, eclectic engineer is passing and I worry about the future of logic design. There’s an adage that says when a carpenter only has a hammer, every problem looks like a nail. Have we reached that point where every problem looks like a software problem?

If you search the internet using the words “FPGA applications” you will find a list of applications at the forefront of electrical engineering. There are applications ranging from artificial intelligence and speech recognition to communications and image processing. The trouble with these applications is that they are not simple; they are not for beginners. The learning curve to master implementation of these applications is steep and includes several non-trivial topics.

One must learn the programmable logic devices themselves, their integrated development environments (IDEs; and every manufacturer has their own), new programming paradigms (i.e. hardware description languages - HDL - and their accommodation of concurrency and the concept of time), and one must understand the application itself. These are practically insurmountable except by experts. This does not bode well to inspire the next generation of logic designer wishing to bootstrap his or her programmable logic skills. The first step is too high. I believe this detracts people from entering the field and thereby diminishes the people who will eventually become tomorrow’s programmable logic zealots. Many stories are on the internet by people expressing frustration with the current state of programmable logic design and there are several open source communities trying to solve this. Many people feel that salvation will come through metaprogramming – a programming technique in which a program treats another program as its data.

Programmable logic companies are in a pinch. On one hand, their investors require them to develop ever more capable and expensive chips and on the other hand, there are relatively fewer people able to use them. Their solution is to convert software developers into hardware designers and they are doing this with new tools.

High level synthesis (HLS) compilers take design abstraction to an even higher level and this takes us even further from the roots of logic design. It’s rather remarkable that we can produce sophisticated hardware designs from purely software descriptions but doing so misses the visceral appeal that logic design can have on people. You won’t find me arguing that a person can “out-optimize” a computer, but I claim it was simpler to design simple circuits in the past. The trouble is that simple circuits are harder to design today than they were in the past.

I remember my sheer delight to see my hand-made logic design work in the form of a circuit. It was my cleverness that minimized the number of devices required. When I learned programmable logic in the early 1990s, I was even more delighted that I could apply my circuit design knowledge to implement my logic in a single device of 128 logic elements and it was my intellect that chose every one of those logic elements. I wasn’t depending on the intellect of some unknown algorithm developer.

While logic design was evolving, so was software design. It has largely become an object-oriented programming (OOP) world and libraries of commonly found design patterns are well documented and readily available in code libraries. My design patterns book is the once popular text by Erich Gamma, et. al., Design Patterns, Elements of Reusable Object-Oriented Software. I find it interesting that hardware design started as object-oriented but its development stalled with the introduction of the HDLs. Even though the HDLs accommodate design reuse, design libraries contain most fundamental functionality. Search “List of 7400-series integrated circuits” on the internet and you can find some early hardware design patterns. I found it interesting that Meilir Page-Jones, in his book, Fundamentals of Object-Oriented Design in UML, references integrated circuits as examples of good object design – high cohesion and low coupling. But in pursuit of ever more complex programmable logic devices, we have lost our roots in simple and direct logic design. Today’s design methodologies depend on a computer algorithm to implement our logic. I think this approach makes a barrier for programmable logic beginners.

You might ask, “How many lines-of-code were in the first Pong game that we plugged into the back of our televisions?” The answer is zero. It was purely hardware (see Figure 1) – no software included! I do not believe there are many newly graduated engineers who could design Pong without using software.  They’d say, “Why should I?” My answer would be “for perspective and because you should know it can be done. It’s simpler than you think.”

Figure 1: Pong schematic (Image: Found via Adafruit blog, unknown origins)

The IEEE published a list of programming languages loved and hated by engineers in early 2019. It said engineers love Python. I believe it. I was a judge at a Texas Instruments design contest several years ago and learned that nine of the 10 college teams used Python for their projects. VHSIC Hardware Description Language (VHDL) and Verilog were not on the loved nor hated lists. Maybe the editors at the IEEE do not consider these HDLs programming languages but, more likely, I bet no one who was surveyed even considered HDLs. If true, this speaks to how few engineers have these languages, or logic design at all, in mind – a bad omen for the field of logic design.

So, what to do? How do we create the mindset in new engineers to look at a problem and consider its solution in software or hardware? After all, most problems can be solved either way. I have an idea.

I think the Arduino platform created multitudes of young people interested in software. They are entering schools to become engineers and computer scientists. How did it do this? Arduino reduced the learning curve to develop software. It made software development less daunting.

By defining a board, one was able to eliminate setting up linker command files, signal names became standard, and its IDE hid compilation details. One of the beauties of Python is that it requires strict formatting – indents must be uniform for example. This eliminates low-value, arbitrary choices with the effect of making the entire development process simpler which, in turn, makes developers more productive. We need the equivalent for programmable logic and it would behoove the programmable logic industry to collaborate on a standard.

Here are some of the attributes that I advocate for that standard. Just as Arduino does not have an inherent and robust capability to modify its underlying architecture such as accommodating nested interrupts, let’s assume the logic problems to be solved on this platform are simple enough that today’s programmable logic devices can meet all timing constraints. The Arduino equivalent, programmable logic device board (PLDB), should have a sufficiently slow clock that any 1,000 logic-element design should work. This means that only functional verification is required by the platform.

Since everyone loves Python, I propose the PLDB be supported with Python and built upon a framework like nMigen or MyHDL (see Figure 2), or even Yosys with its RTLIL. This would allow beginners to simulate their logic designs with an interpreted language, produce truth tables, and access any other Python library available to them. Speaking of Python’s library, using Python also allows the community to use the Python package index (PyPI) to distribute reusable hardware blocks which helps to address the lack of robust, shared, design patterns. nMigen, like Python, supports metaprogramming so, even though this framework will support simple designs, the platform is scalable to support complex designs.

Figure 2: Python-based framework (Image sources: MyHDL.org and m-labs.hk)

The interface from a host PC to a PLDB should be USB along with a PLDB-embedded microcontroller with an API for the host PC to use to learn of the PLDB’s configuration so it can auto-setup the Python environment for programmable logic development. The result of this setup shall be to hide the details of synthesis, place and route, and programming while facilitating functional simulation on the PC and execution on actual hardware.

Lest some readers think there are no longer simple logic problems to solve, I show some statistics on DigiKey’s sales of microcontrollers. Figure 3 shows the breakdown of classes of microcontrollers that customers buy and Figure 4 shows how many units of each class are sold. In all, DigiKey shows over 80,000 microcontroller part numbers and stocks over 19,000 microcontrollers ready for immediate shipment to anywhere in the world. The figures show that simple 8-bit processors are used by more engineers and that DigiKey ships more 8-bit microcontrollers than any other class of processor. This tells me there are more simple problems than complex ones.

Figure 3: Number of DigiKey customers who buy each type of microcontroller (Image source: DigiKey)

Figure 4: Number of units sold of each type of microcontroller from DigiKey (Image source: DigiKey)

Our objective should be to make anyone, even those without a formal education in logic design, into programmable logic enthusiasts; but we’ve got to change development paradigms to do so.