A High Level View of the Design Process

Logic circuits combine input binary signals using AND, OR, and NOT operations to produce binary output signals. The number of input signals that are combined and the logic operations that are used depend on the problem being addressed. For example, imagine a conference room environmental controller with four input sensors (temperature, humidity, smoke, and CO2) and three output control signals (fan, air conditioner, and heater). The controller must: turn on the fan if the temperature is too high OR if smoke is detected AND humidity is low, OR if the CO2 level is too high; turn on the air compressor if humidity AND temperature are too high; and turn on the heater if temperature is too low AND CO2 is NOT high. These requirements can be addressed by a circuit that combines the inputs with the stated logic operations to drive the output signals as desired.

As engineers, we must address two primary concerns: how to unambiguously express a given requirement or problem statement in terms of simple logic relationships so that a circuit can be constructed; and how to build circuits that can be used to implement these relationships in real devices. Restated, we must concisely describe a circuit’s behavior, and then accurately describe its structure, including all required devices and interconnections.

Several methods exist to concisely describe the requirements for a given logic system, including a block diagram, truth tables, logic equations, various hardware description languages, and schematic pictures that show the required circuit elements and their interconnections. The first three methods are “behavioral” descriptions, in that they state how the inputs should be driven as a function of the inputs, but they say nothing about how to construct a circuit. The fourth method (schematics) is a structural description – it shows how to build a circuit, but says nothing about its behavior.

A block diagram simply shows all the input signals that are used by the design, and all the outputs that are produced. When creating the block diagram, all input and output signals should be precisely defined so that it is clear exactly what information is transported into the design, and what new information is produced. Sketching a block diagram and defining the signals forces a clear statement of the design environment and context, and these first steps are essential. After the inputs and outputs are defined, a truth tables shows all possible combinations of input signals, and exactly what the output should be for each combination. Truth tables leave no room for ambiguity, and they are the starting point for many designs (and in particular, the kinds of designs we will pursue in this course). Once a design problem is captured in a truth table, creating a circuit is very straight forward.

Logic equations and behavioral HDL provide a more abstract model of logic circuits. They only state how an output signal should be asserted in response to assertions of inputs, and they leave outputs unasserted for any input combinations not expressly stated. While this is very workable for many problems, there is room for ambiguity (did the designer forget to show some combination of inputs?).

A structural description (like a schematic) shows how to build a circuit, but it is typically not used to capture a design requirement for the first time. A structural design is the end-goal of the entire design effort, and many considerations beyond the circuit’s behavior go into creating a structure for a given circuit (efficiency of resource use, speed of operation, reuse of existing IP blocks, power usage, etc.). Because considerations beyond a circuit’s behavior are implicated in a circuit’s structure, attempting to start a design with a structural description can obscure important design details. A clear and concise behavioral description is just one part of the final structure, and with the rise of behavioral design tools and synthesizers, it is usually the place to start a new design.

The Design Process

A typical design starts with a casual, informal and incomplete description of an intended design, perhaps something like “we should add audio prompts to help the customer use the Widget9000”. While this may sound specific and straight-forward to whomever proposed it, there are many, many issues to resolve. As examples: what quality of audio – what dynamic range (number of bits in a digital sample), what frequency characteristics (number of samples per second); what sort of audio filters are needed; what sort of media will store the audio, and is there enough if it in the system (on-chip ROM, SD card, external ROM); what size and power of speaker are needed; does the system have adequate power available to run the speaker; does the speaker need to be environmentally sealed; in what format will the audio be stored; what sort of Analog to Digital converter (ADC) will be used; what sort of data conversions are required to run the converter; will the ADC use a parallel or serial bus, and what bus exactly; does the processor have enough bandwidth to service the audio needs; will the interrupt system be used; etc.

In the case of a purely digital circuit, the same phenomenon exists – a new design proposal is typically under-thought and incomplete. You should make it a point to completely understand not only the description provided, but also the design intent as much as possible. Design engineers must frequently add, remove, or modify features as the implications of the original design targets become clear during the design process.

Capture the design in a formalism

The first job of an engineer is to convert a design description, in whatever form it is submitted, into a suitable “formal” description. The goal is to remove all ambiguity, and to force whomever is driving the design to commit to a detailed description of all behaviors. Most often, this process is driven by the engineer as the implications and details of the design come into focus.

Several engineering formalisms have been developed to help capture the requirements of an intended design. For new and/or less complex combinational circuit designs, truth tables and block diagrams are typically the best starting points. For new sequential circuits (or software); state or flow diagrams are often used. For more complex designs, top-down partitioning and hierarchical models are used to divide the design into smaller blocks. In this course, we will start with block diagrams and truth tables, and we will include logic equations and Verilog descriptions as needed. The next section looks at these formalisms in detail.

Design a Circuit Structure Based on Design Drivers

After the design is captured in a formalism, it can be analyzed to determine the best structure to build. During this phase, “design drivers” are typically referenced to guide structural choices. Design drivers are subjective criteria that are chosen specifically for each new design to help guide engineers in making trade-offs (choices) as the design progresses. They are generally framed by the system designer, and can include striving for minimal area/resource use, highest operating frequency, lowest power, lowest cost, highest reliability, and other factors. Typically, only one or two drivers can be satisfied, and they often work against each other. For example, the fastest designs often use more transistors and more power, and the smallest designs typically cost more due to the increased cost of using the latest technologies.

Whatever the drivers are, the guide the process of finding a structural circuit that meets the behavioral requirements. In this course, the driver will generally be minimized resource use. Over the next few modules, several methods of analyzing an engineering formalism to find the most efficient/minimal circuit will be presented.

Implement and Verify the Circuit

After the design has been analyzed and cast into a structural form, it can be implemented in a CAD environment. There are several implementation strategies, but most involve entering a design description in a Hardware Design Language (or HDL), including Verilog, in VHDL, or a C-language variant that specifically supports hardware descriptions. In this course, we will use Verilog.

It must be noted that many designs more or less skip the previous “Design a Circuit Structure” step, and progress directly from a formalism to HDL code. Logic synthesizers have become very good at generating circuit structures from a HDL descriptions, and they can also accommodate different design drivers like minimal area or highest speed. In fact in most cases, synthesizers will produce better and more efficient circuit structures than even the most skilled human designers. Engineers still must define a good design partition for more complex designs, but then all the subordinate (or “leaf”) circuit blocks can be designed behaviorally.

After the circuit is implemented, it can be simulated and/or programmed into an FPGA. In the simulation environment, a very accurate computer model of the circuit can be subjected to all possible input patterns in a short amount of time. The performance of all outputs over time, and in fact the performance of all internal circuit nodes as well, can be examined to ensure they are correct for the inputs. The simulator is an enormously powerful and helpful tool throughout the design process, and it is indispensable for even moderately complex circuits. You would be well advised to use the simulator frequently, and to gain as much confidence and competence as you can as soon as you can.

After simulation has demonstrated the correct operation of the structural circuit definition, it can by synthesized and programmed into an FPGA. The synthesis process maps the HDL description onto the physical circuit elements present in the chip that will host the design (in our case, the ZYNQ device from Xilinx). Then after the design is resident in a physical chip, the designer can interact with it and observe how the outputs actually respond to changing inputs. This is often the most revealing step in the entire design process. When real, physical outputs are driven by real inputs, there is no longer any room for misplaced assumptions, flawed explanations, misunderstandings, poor designs, or any other excuses. The design either works and meets requirements, or it doesn’t. If the design doesn’t work properly in hardware, then the behavioral design description may need to change, the design drivers may need to be rethought, the original specifications may need to change, or some combination of these.