SCHEMATIC-BASED DESIGN FLOWS

First, let’s briefly consider the way digital ICs were designed in the days of  old—circa the early 1960s. The purpose of revisiting this ancient history is to  establish an underlying framework that will facilitate understanding the more  advanced design flows introduced in subsequent chapters.   

In those days, electronic circuits were crafted by hand. Circuit diagrams— also known as schematic diagrams or just schematics —were hand-drawn and showed the symbols for the logic gates and functions that were to be used to  implement the design, along with the connections between them. Each design team usually had at least one member who was really good at performing  logic minimization and optimization. Checking that the design would work as  planned insofar as its logical implementation— functional verification —was  typically performed by a group of engineers sitting around a table working  their way through the schematics saying, “ Well, that looks OK. ” Similarly,  timing verification—checking that the design met its required input-to-output  and internal path delays and that no violation times (such as setup and hold  parameters) associated with any of the internal registers were violated—was  performed using a pencil and paper.

Insider Info

The wires connecting the logic gates on an integrated circuit may be referred to as  wires, tracks, or interconnect, and all of these terms may be used interchangeably.  In certain cases, the term metallization may also be used to refer to these tracks  because they are predominantly formed by means of the IC’s metal ( metallization)  layers.

Finally, a set of drawings representing the structures used to form the logic  gates and the interconnections between them were drawn by hand. These drawings, which were formed from groups of simple polygons such as squares  and rectangles, were subsequently used to create the photo-masks, which were  themselves used to create the actual silicon chip.

Not surprisingly, this way of designing was time-consuming and prone to  error. Something had to be done, and a number of companies and universities leapt into the fray in a variety of different directions. In the case of functional  verification, for example, the late 1960s and early 1970s saw the advent of special programs in the form of rudimentary logic simulators .

In order to understand how these work, let’s assume that we have a really  simple gate-level design whose schematic diagram has been hand-drawn on paper ( Figure 5-1 ). In order to use the logic simulator, the engineers first need to  create a textual representation of the circuit called a gate-level netlist. In those  days, the engineers would typically have been using a mainframe c omputer, and  the netlist would have been captured as a set of punched cards called a deck.

As computers (along with storage devices like hard disks) became more accessible, netlists began to be stored as text files ( Figure 5-2 ).

It was also possible to associate delays with each logic gate. These  delays—which are omitted here to keep things simple—were typically referenced as integer multiples of some core simulation time unit.

Note that the format shown in Figure 5-2 was made up purely for the purposes of this example. This was in keeping with the times because—just to  keep everyone on their toes—anyone who created a tool like a logic simulator  also tended to invent his or her own proprietary netlist language.

All of the early logic simulators had internal representations of primitive gates  like AND, NAND, OR, NOR, etc. These were referred to as simulation primitives.  Some simulators also had internal representations of more s ophisticated functions  like D-type flip-flops. In this case, the G4 = DFF function in Figure 5-2 would map directly onto this internal representation. Alternatively, one could create a  subcircuit called DFF, whose functionality was captured as a netlist of primitive  AND, NAND, etc. gates. In this case, the G4 = DFF function in Figure 5-2 would  actually be seen by the simulator as a call to instantiate a copy of this subcircuit.

Next, the user would create a set of test vectors —also known as s timulus — which were patterns of logic 0 and logic 1 values to be applied to the circuit’s inputs. Once again, these test vectors were textual in nature, and they were typically presented in a tabular form looking something like that shown in Figure 5-3 .  The times at which the stimulus values were to be applied were shown in the lefthand column. The names of the input signals are presented vertically to save space.

As we know from Figures 5-1 and 5-2 , there is an inverting (NOT) gate  between the DATA input and the D-type flip-flop. Thus, when the DATA input is presented with 1 at time zero, this value will be inverted to a 0, which is the value  that will be loaded into the register when the clock undergoes a rising (0-to-1) edge  at time 500. Similarly, when the DATA input is presented with 0 at time 1,500, this  value will be inverted to a 1, which is the value that will be loaded into the register  when the clock undergoes its next rising (0-to-1) transition at time 2,000.

In today’s terminology, the file of test vectors shown in Figure 5-3 would  be considered a rudimentary testbench. Once again, time values were typically specified as integer multiples of some core simulation time unit.

The engineer would then invoke the logic simulator, which would read  in the gate-level netlist and construct a virtual representation of the circuit in  the computer’s memory. The simulator would then read in the first test vector  (the first line from the stimulus file), apply those values to the appropriate virtual inputs, and propagate their effects through the circuit. This would  be repeated for each of the subsequent test vectors forming the testbench ( Figure 5-4 ). The simulator would also use one or more control files (or online  co mmands) to tell it which internal nodes (wires) and output pins to monitor, how long to simulate for, and so forth. The results, along with the original  stimulus, would be stored in tabular form in a textual output file.

Let’s assume that we’ve just traveled back in time and run one of the old  simulators using the circuit represented in Figures 5-1 and 5-2 along with the stimulus shown in Figure 5-3 . We will also assume that the NOT gate has a  delay of five simulator time units associated with it, which means that a  change on that gate’s input will take five time units to propagate through the  gate and appear on its output. Similarly, we’ll assume that both the NAND and  OR gates have associated delays of 10 time units, while the D-type flip-flop  has associated delays of 20 time units.

In this case, if the simulator were instructed to monitor all of the internal  nodes and output pins, the output file containing the simulation results would  look something like that shown in Figure 5-5 . For the purposes of our discussions, any changes to a signal’s value are shown in bold font in this illustration, but this was not the case in the real world.

In this example, the initial values are applied to the input pins at time 0. At  this time, all of the internal nodes and output pins show X values, which indicates unknown states. After five time units, the initial logic 1 that was applied  to the DATA input propagates through the inverting NOT gate and appears as  a logic 0 on the internal N_DATA node. Similarly, at time 10, the initial v alues  that were applied to the SET_A and SET_B inputs propagate through the  NAND gate to the internal SET node, while the values on the CLEAR_A and  CLEAR_B inputs propagate through the OR gate to the internal CLEAR node. 

At time 500, a rising (0-to-1) edge on the CLOCK input causes the D-type  flip-flop to load the value from the N_DATA node. The result appears on the Q and N_Q output pins 20 time units later. And so it goes.

Blank lines in the output file, such as the one shown between time 10 and  time 500, were used to separate related groups of actions. For example, setting the initial values at time 0 caused signal changes at times 5 and 10. Then the  transition on the CLOCK input at time 500 caused signal changes at time 520. As these two groups of actions were totally independent of each other, they  were separated by a blank line.

It wasn’t long before engineers were working with circuits that could contain thousands of gates and internal nodes along with simulation runs that  could encompass thousands of time steps.

Back-end Tools like Layout

As opposed to tools like logic simulators that were intended to aid the engineers who were defining the function of ICs (and circuit boards), some companies focused on creating tools that would help in the process of laying the ICs  out. In this context, layout refers to determining where to place the logic gates  (actually, the transistors forming the logic gates) on the surface of the chip and  how to route the wires between them.   
These tools started out as early computer-aided drafting tools and evolved  into interactive programs called polygon editors that allowed users to draw the  polygons used to define the transistors and interconnect directly onto the computer screen. Descendants of these tools eventually gained the capability to  accept the same netlist used to drive the logic simulator and to perform the  layout (place-and-route) tasks automatically. 

CAE + CAD = EDA

Tools like logic simulators that were used in the front-end (logical design capture and functional verification) portion of the design flow were originally gathered together under the umbrella name of computer-aided engineering(CAE). By comparison, tools like layout ( place-and-route ) that were used in the back-end (physical) portion of the design flow were originally gathered together under the name of computer-aided design (CAD). 

Sometime during the 1980s, all of the CAE and CAD tools used to design electronic components and systems were gathered under the name electronic design automation , or EDA.

Insider Info  

For historical reasons that are largely based on the origins of the terms CAE and  CAD, the term design engineer—or simply engineer—typically refers to someone  who works in the front-end of the design flow; that is, someone who performs tasks  like conceiving and describing (capturing) the functionality of an IC (what it does  and how it does it). By comparison, the term layout designer—or simply designer— commonly refers to someone who is ensconced in the back-end of the design flow;  that is, someone who performs tasks such as laying out an IC (determining the  locations of the gates and the routes of the tracks connecting them together).

A simple (early) Schematic-driven ASIC Flow

Toward the end of the 1970s and the beginning of the 1980s, some companies  started providing graphical schematic capture programs that allowed engineers  to create circuit (schematic) diagrams interactively. Using the mouse, an engineer could select symbols representing such entities as I/O pins and logic gates and functions from a special symbol library and place them on the screen.  The engineer could then use the mouse to draw lines (wires) on the screen connecting the symbols together.

Once the circuit had been entered, the schematic capture package could  be instructed to generate a corresponding gate-level netlist. This netlist could  first be used to drive a logic simulator to verify the functionality of the design.  The same netlist could then be used to drive the place-and-route software ( Figure 5-6 ).

Any timing information that was initially used by the logic simulator  would be estimated—particularly in the case of the tracks—and accurate timing analysis was only possible once all of the logic gates had been placed and  the tracks connecting them had been routed. Thus, following place-and-route,  an extraction program would be used to calculate the parasitic resistance and  capacitance values associated with the structures (track segments, vias, transistors, etc.) forming the circuit. A timing analysis program would then use  these values to generate a timing report for the device. In some flows, this timing information was also fed back to the logic simulator in order to perform a  more accurate simulation.

—Technology Trade-offs—

● It’s important to note here that, when creating the original schematic, the user  would access the symbols for the logic gates and functions from a special

library that was associated with the targeted ASIC technology. Similarly, the  simulator would be instructed to use a corresponding library of s imulation models with the appropriate logical functionality and timing for the targeted  ASIC technology. The result was that the gate-level netlist presented to the place-and-route software directly mapped onto the logic gates and f unctions  being physically implemented on the silicon chip. This is a tad different from the FPGA flow, as discussed in the following subsection.

A Simple (early) Schematic-driven FPGA Flow

When the first FPGAs arrived on the scene in 1984, it was natural that their  design flows would be based on existing schematic-driven ASIC flows.  Indeed, the early portions of the flows were very similar in that, once again, a  schematic capture package was used to represent the circuit as a collection of  primitive logic gates and functions and to generate a corresponding gate-level  netlist. As before, this netlist was subsequently used to drive the logic simulator to perform the functional verification.

The differences began with the implementation portion of the flow because  the FPGA fabric consisted of an array of configurable logic blocks (CLBs), each  of which was formed from a number of LUTs and registers. This required the  introduction of some additional steps called mapping and packing into the flow  ( Figure 5-7 ).

Mapping

In this context, mapping refers to the process of associating entities such as  the gate-level functions in the gate-level netlist with the LUT-level functions   available on the FPGA. Of course, this isn’t a one-for-one mapping because  each LUT can be used to represent a number of logic gates ( Figure 5-8 ).  Mapping (which is still performed today, but elsewhere in the flow, as will  be discussed later) is a nontrivial problem because there are a large number  of ways in which the logic gates forming a netlist can be partitioned into the  smaller groups to be mapped into LUTs. As a simple example, the functionality of the NOT gate shown in Figure 5-8 might have been omitted from this  LUT and instead incorporated into the upstream LUT driving wire c.

Packing

Only 12 of the 24 possible permutations are shown here. Furthermore, in reality there are actually only 12 permutations of significance because each has  a “ mirror image ” that is functionally its equivalent, such as the AC-BD and  BD-AC pairs shown in Figure 5-9 . The reason for this is that when we come to  place-and-route, the relative locations of the two CLBs can be exchanged.

Place-and-route

Following packing, we move to place-and-route . With regard to the pr evious  point, let’s assume that our two CLBs need to be connected together, but  that—purely for the purposes of this portion of our discussions—they can only  be placed horizontally or vertically adjacent to each other, in which case there  are four possibilities ( Figure 5-10 ).   

In the case of placement (i) for example, if CLB 1 contained LUTs A-C  and CLB 2 contained LUTs B-D, this would be identical to swapping the positions of the two CLBs and exchanging their contents.   

If we only had the two CLBs shown in Figure 5-10 , it would be easy to  determine their optimal placement with respect to each other (which would  have to be one of the four options shown above) and the absolute placement of  this two-CLB group with respect to the entire chip.

—Technology Trade-offs—

● The placement problem is much more complex in the real world because  a real design can contain extremely large numbers of CLBs. In addition to  CLBs 1 and 2 being connected together, they will almost certainly need  to be connected to other CLBs. For example, CLB 1 may also need to be  connected to CLBs 3, 5, and 8, while CLB 2 may need to be connected  to CLBs 4, 6, 7, and 8. And each of these new CLBs may need to be connected to each other or to yet more CLBs. Thus, although placing CLBs 1  and 2 next to each other would be best for them, it might be detrimental to  their relationships with the other CLBs, and the most optimal solution overall might be to separate CLBs 1 and 2 by some amount.

Although placement is difficult, deciding on the optimal way to route the signals between the various CLBs poses an even more Byzantine problem. The  complexity of these tasks is mind-boggling, so we’ll leave it to those guys and  gals who write the place-and-route algorithms.  

Flat versus Hierarchical Schematics  

Clunky Flat Schematics

The very first schematic packages essentially allowed a design to be captured  as a humongous, flat circuit diagram split into a number of “ pages. ” You created a single flat schematic as a series of pages linked together by interpage  connector symbols, where the names you gave these symbols told the system  which ones were to be connected together. For example, consider a simple circuit sketched on a piece of paper ( Figure 5-11 ).

Assume that the gates on the left represent some control logic, while the  four registers on the right are implementing a 4-bit shift register. Obviously,  this is a trivial example, and a real circuit would have many more logic gates.  We’re just trying to tie down some underlying concepts here, such as the fact  that when you entered this circuit into your schematic capture system, you  might split it into two pages ( Figure 5-12 ).

Sleek Hierarchical (block-based) Schematics  

There were a number of problems associated with the flat schematics, especially when dealing with real-world circuits requiring 50 or more pages:  

● It was difficult to visualize a high-level, top-down view of the design.  

● It was difficult to save and reuse portions of the design in future projects.  

● In the case of designs in which some portion of the circuit was repeated  multiple times (which is very common), that portion would have to be  redrawn or copied onto multiple     pages. This became very painful if you  subsequently realized that you had to make a change because you would  have to make the same change to all the copies.

The answer was to enhance schematic capture packages to support the concept  of hierarchy. In the case of our shift register circuit, for example, you might start  with a top-level page in which you would create two blocks called control and  shift, each with the requisite number of input and output pins. You would then  connect these blocks to each other and to some primary inputs and outputs.   

Next, you would instruct the system to “ push down ” into the control block,  which would open a new schematic page. If you were lucky, the system would  automatically pre-populate this page with input and output connector symbols (and  with associated names) corresponding to the pins on its parent block. You would  then create the schematic corresponding to that block as usual ( Figure 5-13 ).

In fact, each block could contain a further block-level schematic, or a gatelevel schematic, or (very commonly) a mixture of both. These hierarchical  block-based schematics answered the problems associated with flat schematics:  

● They made it easier to visualize a high-level, top-down view of the design  and to work one’s way through the design.  

● They made it easier to save and reuse portions of the design in future projects.  

● In the case of designs in which some portion of the circuit was repeated  multiple times, it was only necessary to create that portion—as a discrete  block—once and then to instantiate (call) that block multiple times. This  made things easy if you subsequently realized that you had to make a change  because you would only have to modify the contents of the initial block.

Schematic-driven FPGA Design Flows Today  

All of the original schematic, mapping, packing, and place-and-route applications were typically created and owned by the FPGA companies. However, the  general feeling is that a company can either be good at creating EDA tools or  it can be good at creating silicon chips, but not both.   

Another facet of the problem is that design tools were originally extremely  expensive in the ASIC world (even tools like schematic capture, which today  are commonly regarded as commodity products). By comparison, the FPGA  vendors were focused on selling chips, so right from the get-go they offered  their tools at a very low cost (in fact, if you were a big enough customer,  they’d give you the entire design tool suite for free). While this had its obvious  attractions to the end user, the downside was that the FPGA vendors weren’t  too keen on spending vast amounts of money enhancing tools for which they  received little recompense.   

Over time, therefore, external EDA vendors started to supply portions of  the puzzle, starting with schematic capture and then moving into mapping and  packing. Having said this, the FPGA vendors still typically provide internally  developed, less sophisticated (compared to the state-of-the-art) versions of  tools like schematic capture as part of their basic tool suite, and they also maintain a Vulcan Death Grip on their crown jewels (the place-and-route software).

Insider Info

For many engineers today, driving a design using schematic capture at the gatelevel of abstraction is but a distant memory. In some cases, FPGA vendors offer little support for this type of flow for their latest devices to the extent that they only  provide schematic libraries for older component generations. However, schematic  capture does still find a role with some older engineers and with folks who need  to make minor functional changes to legacy designs. Furthermore, graphical entry  mechanisms that are descended from early schematic capture packages still find a  place in modern design flows.