Tabular Design Formats:Netlist Formats.

Netlist Formats

Netlists describe circuits in a textual list format. They are normally of structural type and have two main targets:

• Enumeration of all devices (or parts) including the input and output pins;

• Enumeration of all connections between the device pins.

Devices are uniquely identified by their part name and their instance name. Multiple devices with the same part name are distinguishable through their instance name (see chapter 3). Node names are either entered by the user or are generated automat- ically with running numbers by the schematic editor or the synthesis program. The path gets added to the part names and node names in hierarchical design structures.

A signal describes the electrical information on a node; in the following descriptions both expressions, signal and node, are used synonymously.

In principle, there are two different basic types of netlists: device oriented and node oriented netlists.

Device Oriented Netlists

In such a netlist a single device and all the nodes that are connected to it are listed in one line. In the following example, the instance name is placed first. The number of pins may vary from one device to another. In a positional pin list the exact sequence of pins is implicitly defined. Thus, the position in the list of nodes describes exactly to which pin it is connected.

In device oriented netlists the instance is named once only and the nodes as often as there are pins to which they get connected. An agreement has to exist regarding the position of pins because they are not named explicitly.

Tabular Design Formats-0074

Variations of the netlist formats exist where the pin names are explicitly assigned to the connected node. In such named pin lists the sequence of the pin assignment is irrelevant. In hierarchical designs the information of the hierarchy level is included in the instance names as well as in the node names. A common way of adding the level information is to list the sub-design names with a

Tabular Design Formats-0075

Node Oriented Netlists

In such a netlist all the devices are listed in a first section together with their instance names (for example, section PARTS). Afterwards pins connected to one node are listed after the node name (for example, section NETS). Every single pin has to be identified with the individual device to which it belongs by the distinguishable instance name. In the following list, the pin name appears as a qualifier of the instance name. The instance

Tabular Design Formats-0076

Both types of format can be conversely converted because they carry exactly the same information. The preference for one or the other type depends mainly on the tool that has to scan the lists for further processing.

Simulators access the part properties more often. In that case part oriented lists are normally used. A Place&Route program has to process the nodes more often; this leads to a preferred use of node oriented netlists.

The SPICE Format

The SPICE (Simulation Program with Integrated Circuit Emphasis) format has a typical device oriented structure with positional signals. It contains the circuit data (and control statements) for sim- ulation. It has stayed stable since its introduction in the 1970s and has become an industry standard over the years owing to its simplicity and robust- ness. A complete description of all elements and control statements can be found in [8.1].

The Format of SPICE Netlists

Each SPICE line begins with an element description because it is a device oriented format. At least two positional nodes follow, as well as the model assignment. After that optional parameters can be passed to the device model. The format has the following general structure (see [8.1], Appendix C):

Tabular Design Formats-0077

Tabular Design Formats-0078

• Node: Node name. The positional sequence of pins is defined in the SPICE reference for each element. There are at least two pins per device. The original SPICE netlist definition allowed only net numbers. In ORCAD’s PSPICE, this limitation has been removed, enabling the user to edit the node names in the schematic editor.

• Model: Pointer to a .MODEL entry which is built into the SPICE code. This entry is optional.

• Value: A optional numerical entry for the property of a device, for example the value of a resistor.

• Parameter: Names and values of further parameters to be passed on to the model description. Without a specific entry the model default values are used.

• +: Continuation character to signal that the last line gets extended.

.., Note: The schematic editor of PSICE allows the user to re-edit any instance name into a symbolic name with an arbitrary sequence of characters. While generating the netlist the device identifier ID is added in front of the symbolic name with an underscore. Thus the identification of the element is guaranteed. For example, R2 becomes R_R2 and myres5 becomes R_myres5.

The Format of Control Statements

In general all control statements start with a period ‘ . ’ and are followed by parameters:

Tabular Design Formats-0079

Tabular Design Formats-0080

• Parameter: Key word, value, or text. Depending on the type of control statement, the parameters may have a varying meaning. A detailed description is found in [8.1], Appendix B.

Example of a SPICE Netlist

List 8.1 shows the netlist of a circuit with an operational amplifier (comments added by hand). The circuit contains resistors and capacitors for a second order low pass filter. The nodes are symbolically named, which is understood by PSPICE. This list may directly be fed into PSPICE A/D. The circuit will simulate as long as the library ‘eval.lib’ contains a .subcircuit uA741 defining the operational amplifier.

Comments

Post a Comment

Popular posts from this blog

Design using Standard Description Languages:The simulation model in VHDL

Image
The simulation model in VHDL After a look at concurrent signal statements in chapter 4.3, basic mechanisms of the language can be discussed in detail. Originally the language VHDL was developed for simulation only. A dis- cussion about the theory of operation of a VHDL simulator helps to understand VHDL modelling and simplifies the choice of suitable language constructs to describe hardware constructs. The topic simulation model has an emphasis on: • Driving signals; • Delta delay mechanisms; • Modelling of delay times. Drivers Every concurrent statement, including processes, causes an event responsible for the progress of a signal. Within the simulator there is a list containing points in time to schedule signal events. Such an entry in that list is called a transaction. This list is the basic information for scheduling signal values during simulation (fig. 4.22). A change of a signal value caused by an entry in that list, is called an event in that signal. If a new entry is the ...
Read more

EDA Tutorial:Place and Route in a Standard Cell Design Style

Image
Place and Route in a Standard Cell Design Style In the design of FPGA circuits, after the synthesis of the EDIF files, the compiling and programming of the FPGA device, everything is defined and the component is completely configured. With ASIC designs, there are two possible scenarios: • Delivery of the design to an ASIC provider in the form of a so called simulate d netlist (EDIF); • Place and Route of the design with one’s own tools, verification of the results, and delivering of the design as a geometrically exact GD S II File . For similar designs in industry the netlist version is frequently chosen, but here the second scenario which includes the bac k en d processing , the phys- ical design, will be demonstrated in more detail. This needs special software tools, which allow the mask design at the lowest geometry level, and tools for checking the generated geometries against the predefined design rules ( Desig n Rule Che c k , DRC ), and allow one to extract parasitics and el...
Read more

Overview of EDA Tools and Design Concepts:Major Classes of EDA Tools.

Image
Introduction In the next few chapters, we will discuss specific kinds of EDA tools. In this chapter, we provide an overview of the EDA tool world. There are several EDA-related concepts which are helpful to understand the EDA tools and the design process. These include: Design Views Hierarchy Design Chip Architecture Methodology Design Flow Tool Suites Nora of Sandbox, Inc., is meeting again with Andrea, an ASIC engineer who works for Fabless Design, Inc. Nora has asked to learn more about the use of EDA tools. Let us listen in on their discussion. Nora: Hello again, Andrea. Did you like the party the other evening? Andrea: Yes, very much. Sandbox has both outstanding tools and great parties. Nora: We seem to be continually developing new tools. I am a little unclear why that is. Tool Improvements Andrea: That's because each generation of semiconductor process improvements shrinks the size of the transistors and wires. The number of transistors and wires...
Read more