Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Netlist
View on Wikipedia
 | This article needs additional citations for verification. (April 2019) |
In electronic design, a netlist is a description of the connectivity of an electronic circuit.[1][2] In its simplest form, a netlist consists of a list of the electronic components in a circuit and a list of the nodes they are connected to.[1][3] A network (net) is a collection of two or more interconnected components.
The structure, complexity and representation of netlists can vary considerably, but the fundamental purpose of every netlist is to convey connectivity information. Netlists usually provide nothing more than instances, nodes, and perhaps some attributes of the components involved.[4] If they express much more than this, they are usually considered to be a hardware description language such as Verilog or VHDL, or one of several languages specifically designed for input to simulators or hardware compilers (such as SPICE analog simulation netlists).
Types of netlists
[edit]Netlists can be:
- Physical (based upon physical connections) or logical (based upon logical connections)
- For example, connecting three components through one terminal of one of those components would be considered a direct logical connection, whereas each would be discrete physical connections.
- Instance-based (clustered about a component instance) or net-based (exhaustive list of connections to a particular net)
- Flat (all connections are shown) or hierarchical (connections are grouped in some way; such as which physical board or layer they are connected to. Such netlists may in addition be either folded, hiding data beneath a given level of abstraction, or unfolded, being exhaustive and thus potentially equivalent in content to flat netlists.)
Contents and structure of a netlist
[edit]Most netlists either contain or refer to descriptions of the parts or devices used. Each time a part is used in a netlist, this is called an "instance".
These descriptions will usually list the connections that are made to that kind of device, and some basic properties of that device. These connection points are called "terminals" or "pins", among several other names.
An "instance" could be anything from a MOSFET transistor or a bipolar junction transistor, to a resistor, a capacitor, or an integrated circuit chip.
Instances have "terminals". In the case of a vacuum cleaner, these terminals would be the three metal prongs in the plug. Each terminal has a name, and in continuing the vacuum cleaner example, they might be "Neutral", "Live" and "Ground". Usually, each instance will have a unique name, so that if you have two instances of vacuum cleaners, one might be "vac1" and the other "vac2". Besides their names, they might otherwise be identical.
Networks (nets) are the "wires" that connect things together in the circuit. There may or may not be any special attributes associated with the nets in a design, depending on the particular language the netlist is written in, and that language's features.
Instance based netlists usually provide a list of the instances used in a design. Along with each instance, either an ordered list of net names is provided, or a list of pairs provided, of an instance port name, along with the net name to which that port is connected. In this kind of description, the list of nets can be gathered from the connection lists, and there is no place to associate particular attributes with the nets themselves. SPICE is an example of instance-based netlists.
Net-based netlists usually describe all the instances and their attributes, then describe each net, and say which port they are connected on each instance. This allows for attributes to be associated with nets. EDIF is probably the most famous of the net-based netlists.
Hierarchy
[edit]In large designs, it is a common practice to split the design into pieces, each piece becoming a "definition" which can be used as instances in the design. In the vacuum cleaner analogy, one might have a vacuum cleaner definition with its ports, but now this definition would also include a full description of the machine's internal components and how they connect (motors, switches, etc.), like a wiring diagram does.
A definition which includes no instances is called a "primitive" (or a "leaf", or other names); whereas a definition which includes instances is "hierarchical".
A "folded" hierarchy allows a single definition to be represented several times by instances. An "unfolded" hierarchy does not allow a definition to be used more than once in the hierarchy.
Folded hierarchies can be extremely compact. A small netlist of just a few instances can describe designs with a very large number of instances. For example, suppose definition A is a simple primitive, like a memory cell. Then suppose definition B contains 32 instances of A; C contains 32 instances of B; D contains 32 instances of C; and E contains 32 instances of D. The design now contains 5 definitions (A through E) and 128 instances. Yet, E describes a circuit that contains over a million memory cells.
Unfolding
[edit]In a "flat" design, only primitives are instanced. Hierarchical designs can be recursively "exploded" ("flattened") by creating a new copy (with a new name) of each definition each time it is used. If the design is highly folded, expanding it like this will result in a much larger netlist database, but preserves the hierarchy dependencies. Given a hierarchical netlist, the list of instance names in a path from the root definition to a primitive instance specifies the single unique path to that primitive. The paths to every primitive, taken together, comprise a large but flat netlist that is exactly equivalent to the compact hierarchical version.
Backannotation
[edit]Backannotation is data that could be added to a hierarchical netlist. Usually they are kept separate from the netlist, because several such alternate sets of data could be applied to a single netlist. These data may have been extracted from a physical design, and might provide extra information for more accurate simulations. Usually the data are composed of a hierarchical path and a piece of data for that primitive or finding the values of RC delay due to interconnection.
Inheritance
[edit]Another concept often used in netlists is that of inheritance. Suppose a definition of a capacitor has an associated attribute called "Capacitance", corresponding to the physical property of the same name, with a default value of "100 pF" (100 picofarads). Each instance of this capacitor might also have such an attribute, only with a different value of capacitance. And other instances might not associate any capacitance at all. In the case where no capacitance is specified for an instance, the instance will "inherit" the 100 pF value from its definition. A value specified will "override" the value on the definition. If a great number of attributes end up being the same as on the definition, a great amount of information can be "inherited", and not have to be redundantly specified in the netlist, saving space, and making the design easier to read by both machines and people.
References
[edit]- ^ a b Holt, Randy. "Schematic vs. Netlist: A Guide to PCB Design Integration". blog.optimumdesign.com. Archived from the original on 2019-07-16. Retrieved 2019-04-03.
- ^ "netlist.html". www.vlsiip.com. Retrieved 2019-04-03.
- ^ "Netlist File Format" (PDF). www.expresspcb.com. Retrieved August 24, 2021.
The netlist is written in a single file, but includes four sections: 1) A file header, 2) A table listing each of the components, 3) A table listing each of the net names, 4) A table listing each of the net connections. Every table entry is written using a single line of text that ends with a CRLF. The fields of the table are separated with Space characters (0x20). String fields begin and end with double quotes. Each of the three tables are terminated by a blank line (CRLF).
- ^ "Example Circuits and Netlists | Using The spice Circuit Simulation Program | Electronics Textbook". www.allaboutcircuits.com. Retrieved 2019-04-03.
Further reading
[edit]Netlist
View on GrokipediaFundamentals
Definition and Purpose
A netlist is a textual or graphical description of the connectivity in an electronic circuit, specifying the components—such as gates, transistors, or other primitives—and the nets that interconnect their pins or terminals.[3] This representation abstracts the circuit's topology, focusing solely on logical or electrical connections without detailing physical layout or geometry.[2] The primary purpose of a netlist is to serve as a standardized intermediate format in electronic design automation (EDA) workflows, enabling the transfer of circuit topology between tools for processes like logic synthesis, simulation, place-and-route, and verification.[5] By providing a portable, tool-agnostic description of the design, it allows abstraction from specific implementation details, facilitating seamless integration across diverse EDA environments.[3] Netlists originated in the late 1960s and early 1970s as EDA tools emerged for integrated circuit (IC) design, evolving from manual wire lists used in printed circuit board (PCB) manufacturing to automated digital representations.[6] A key milestone was the development of netlist programs within the SCALD (Structured Computer-Aided Logic Design) toolset at the University of California, Berkeley, starting in 1975 for the Lawrence Livermore National Laboratory's S-1 supercomputer project, where they automated connectivity extraction from schematic captures.[7] Key benefits of netlists include enabling automated error checking, such as layout-versus-schematic (LVS) verification to detect connectivity mismatches, supporting design optimization through synthesis and timing analysis, and promoting portability by avoiding proprietary tool formats.[8] These attributes make netlists essential for efficient, reliable circuit design across scales from PCBs to complex ICs. Variations like flat and hierarchical netlists represent adaptations of this core concept to different design complexities.[2]Basic Components
In a netlist, components form the fundamental building blocks of the circuit, consisting of primitive elements such as resistors, capacitors, logic gates, or transistors that perform specific electrical functions.[2] Each component is uniquely identified by a reference designator, such as R1 for a resistor or U1 for an integrated circuit, allowing for precise tracking within the design.[3] These elements encapsulate the circuit's logic or analog behavior, serving as the atomic units from which larger designs are constructed.[9] Nets represent the interconnections between components, acting as electrical pathways that link multiple points in the circuit to establish connectivity.[2] Typically depicted as wires for single signals or buses for grouped multi-bit signals, nets ensure that signals propagate correctly between elements, defining the overall topology without specifying physical routing.[3] For instance, a net named GND might connect all ground pins across components to form a common reference.[9] Nodes, often referred to as pins, are the specific connection terminals on components where nets attach, enabling the attachment of signals or power.[2] Each pin has a designated name or number and may include electrical properties such as directionality—input for receiving signals, output for driving signals, or bidirectional for both—along with attributes like voltage levels or impedance.[3] These points serve as the interfaces that nets bridge, ensuring accurate representation of circuit interactions.[9] A simple netlist structure might declare components followed by their pin connections to nets, as in the following excerpt:R1 (1 2)
C1 (1 2)
NET1: R1.1 C1.1
NET2: R1.2 C1.2
R1 (1 2)
C1 (1 2)
NET1: R1.1 C1.1
NET2: R1.2 C1.2
Types
Flat Netlists
A flat netlist represents an electronic circuit at a single level of abstraction, explicitly listing all components, pins, and interconnections without any modular or subcircuit references.[3] This structure treats the entire design as one cohesive module, expanding any potential hierarchy into a complete, non-redundant enumeration of elements.[10] One key advantage of flat netlists is their simplicity, which facilitates straightforward parsing and processing by tools that lack built-in support for hierarchical data.[3] They are particularly well-suited for simulation environments like SPICE, where the absence of nested structures streamlines electrical analysis and verification.[3] Despite these benefits, flat netlists have notable drawbacks, especially for complex designs, as they result in expansive files that amplify redundancy and complicate manual inspection or debugging.[3] The lack of abstraction can lead to inefficient storage and slower handling in memory-intensive operations.[11] Flat netlists find primary use in applications such as PCB routing, where explicit connectivity is needed for layout tools, and in basic logic or timing simulations that prioritize direct net traversal over scalability.[3] They also serve as a standard export format from schematic capture software to ensure accurate transfer of design intent to downstream processes like post-layout verification.[3] As a simpler alternative to hierarchical netlists, flat representations excel in small-scale designs but scale poorly for larger systems.[3] For illustration, consider a basic CMOS inverter circuit. A corresponding flat netlist in SPICE format explicitly defines the transistors, supply, input stimulus, and analysis directives without any subcircuits:* Simple Flat SPICE Netlist for CMOS Inverter
.global Vdd Gnd
* Transistor Models (simplified)
.model nmos NMOS Level=1 Vto=0.7 Kp=120u
.model pmos PMOS Level=1 Vto=-0.7 Kp=40u
* NMOS Transistor
M1 out in Gnd Gnd nmos L=0.5u W=2u
* PMOS Transistor
M2 out in Vdd Vdd pmos L=0.5u W=4u
* [Power Supply](/page/Power_supply)
Vdd Vdd Gnd DC 1.8
* Input Stimulus
Vin in Gnd PULSE(0 1.8 0 0.1n 0.1n 1n 2n)
* Load Capacitance (optional for [simulation](/page/Simulation))
Cload out Gnd 10f
* Transient [Analysis](/page/Analysis)
.tran 0.01n 10n
.end
* Simple Flat SPICE Netlist for CMOS Inverter
.global Vdd Gnd
* Transistor Models (simplified)
.model nmos NMOS Level=1 Vto=0.7 Kp=120u
.model pmos PMOS Level=1 Vto=-0.7 Kp=40u
* NMOS Transistor
M1 out in Gnd Gnd nmos L=0.5u W=2u
* PMOS Transistor
M2 out in Vdd Vdd pmos L=0.5u W=4u
* [Power Supply](/page/Power_supply)
Vdd Vdd Gnd DC 1.8
* Input Stimulus
Vin in Gnd PULSE(0 1.8 0 0.1n 0.1n 1n 2n)
* Load Capacitance (optional for [simulation](/page/Simulation))
Cload out Gnd 10f
* Transient [Analysis](/page/Analysis)
.tran 0.01n 10n
.end
in to gates, out to drains, Gnd and Vdd to sources) and nets directly, enabling immediate simulation of the inverter's switching behavior.[12]
Hierarchical Netlists
Hierarchical netlists organize circuit designs into a tree-like structure of interconnected modules or cells, where lower-level blocks containing their own internal netlists are instantiated within higher-level modules to represent complex systems without duplicating definitions.[10] This modular approach contrasts with flat netlists by enabling scalable representation of large designs through layered abstraction.[4] Key features of hierarchical netlists include explicit module definitions that encapsulate connectivity details, instantiation statements specifying how lower-level modules are placed and connected via port mappings (e.g.,INST1 moduleA (.port1(signal1), .port2(signal2))), and support for global nets that propagate signals across multiple hierarchy levels.[4] These elements allow EDA tools to traverse the hierarchy while preserving the modular boundaries during design flows.[13]
The primary benefits of hierarchical netlists lie in their facilitation of design reuse, where verified intellectual property (IP) blocks can be instantiated repeatedly across projects, and their promotion of efficient storage and management for very-large-scale integration (VLSI) circuits by minimizing file size and redundancy.[14] They also enable top-down design methodologies, permitting architects to refine high-level structures before detailing lower levels, which streamlines collaboration in team-based VLSI development.[15]
A notable challenge in handling hierarchical netlists is the requirement to resolve inter-module connections, often necessitating hierarchy traversal or partial flattening during processing stages like simulation or optimization, which can increase computational overhead in EDA tools.[13]
As an illustrative example, consider a 4-bit ripple-carry adder, where a top-level module instantiates multiple full-adder submodules to handle bit-wise addition with carry chaining:
module full_adder (
input wire a, b, cin,
output wire sum, cout
);
assign sum = a ^ b ^ cin;
assign cout = (a & b) | (a & cin) | (b & cin);
endmodule
module four_bit_adder (
input wire [3:0] a, b,
input wire cin,
output wire [3:0] sum,
output wire cout
);
wire [2:0] carry;
full_adder fa0 (.a(a[0]), .b(b[0]), .cin(cin), .sum(sum[0]), .cout(carry[0]));
full_adder fa1 (.a(a[1]), .b(b[1]), .cin(carry[0]), .sum(sum[1]), .cout(carry[1]));
full_adder fa2 (.a(a[2]), .b(b[2]), .cin(carry[1]), .sum(sum[2]), .cout(carry[2]));
full_adder fa3 (.a(a[3]), .b(b[3]), .cin(carry[2]), .sum(sum[3]), .cout(cout));
endmodule
module full_adder (
input wire a, b, cin,
output wire sum, cout
);
assign sum = a ^ b ^ cin;
assign cout = (a & b) | (a & cin) | (b & cin);
endmodule
module four_bit_adder (
input wire [3:0] a, b,
input wire cin,
output wire [3:0] sum,
output wire cout
);
wire [2:0] carry;
full_adder fa0 (.a(a[0]), .b(b[0]), .cin(cin), .sum(sum[0]), .cout(carry[0]));
full_adder fa1 (.a(a[1]), .b(b[1]), .cin(carry[0]), .sum(sum[1]), .cout(carry[1]));
full_adder fa2 (.a(a[2]), .b(b[2]), .cin(carry[1]), .sum(sum[2]), .cout(carry[2]));
full_adder fa3 (.a(a[3]), .b(b[3]), .cin(carry[2]), .sum(sum[3]), .cout(cout));
endmodule
four_bit_adder module reuses the full_adder definition four times, demonstrating how hierarchy promotes modularity and reduces repetition in netlist descriptions.[16]
Structure and Formats
Core Elements
Netlists employ a standardized syntax for describing circuit connectivity, primarily through directives that instantiate components, declare nets, and specify attributes. Component instantiation typically involves a unique instance name, a reference to the component type or library cell, and connections mapping pins to nets, ensuring precise linkage between elements. In digital formats like Verilog and VHDL, nets are explicitly declared as wires or signals using alphanumeric identifiers to represent electrical connections, while in analog formats like SPICE, nets are implicitly defined by node labels in component statements.[17][18] Attributes such as timing delays, power consumption values, or load capacitances are appended as parameters to components or nets, allowing for the inclusion of non-structural properties that influence simulation or optimization.[19][20] Organizational principles in netlists often allow flexible ordering to maintain parseability and logical flow, though some representations encourage component or declaration statements before connections for clarity and incremental parsing. Scoping distinguishes local nets, confined to a module or subcircuit, from global signals accessible across the design, preventing unintended cross-references while supporting modular construction. Comments, denoted by symbols like asterisks or semicolons, are interspersed to annotate sections without affecting execution, aiding readability during manual review or debugging. These rules, rooted in parser efficiency, ensure that electronic design automation (EDA) tools can systematically interpret the file.[21] Common pitfalls in netlist construction include ambiguous naming, where overlapping identifiers lead to misinterpretation by tools, unconnected pins that result in incomplete circuits, and floating nets lacking sufficient terminations, which can cause simulation instabilities or synthesis failures. Basic validation concepts, such as electrical rule checks (ERC), systematically scan for these issues by verifying pin connectivity, net continuity, and naming uniqueness, often flagging violations before proceeding to layout or simulation stages. Nets and pins serve as the fundamental building blocks, with validation ensuring their proper assembly into functional designs.[22][23] Netlists operate at varying abstraction levels, with logical or behavioral variants emphasizing functional connectivity through high-level primitives like gates or registers, abstracting away physical details to focus on signal flow and logic. In contrast, physical netlists incorporate layout-specific information, such as wire lengths or layer assignments, prioritizing spatial connectivity for routing and fabrication. This distinction by connectivity focus enables seamless transitions from design verification to implementation.[15] Standardization efforts have shaped netlist conventions through IEEE standards like 1076 for VHDL, which influences syntax for hierarchical descriptions and signal declarations in generated netlists, promoting interoperability across EDA tools. VHDL's structured approach to entities, ports, and generics has informed broader netlist practices, ensuring consistent handling of components and attributes in diverse workflows.[24][25]Common Representations
Netlists are commonly represented in text-based formats that facilitate human readability and tool interoperability in electronic design automation (EDA) workflows. One prominent example is the SPICE format, primarily used for analog circuit simulation, where circuits are described using simple ASCII lines specifying components, nodes, and parameters. For instance, a resistor is denoted as *R1 1 2 1k, indicating a 1 kΩ resistor connected between nodes 1 and 2, with node numbering providing a straightforward way to define connectivity.[20] Subcircuit definitions in SPICE employ .SUBCKT statements to encapsulate reusable blocks, enabling hierarchical descriptions while maintaining a flat connectivity view when expanded.[20] Hardware description languages (HDLs) offer structured text-based representations for digital netlists, emphasizing modularity and synthesis compatibility. In structural Verilog, netlists are expressed through module instantiations, wires, and assignments that mirror gate-level connectivity; an example is:wire net1;
assign net1 = gate1.out;
wire net1;
assign net1 = gate1.out;
Hierarchy Techniques
Unfolding
Unfolding in netlist processing refers to the recursive expansion of a hierarchical netlist into a flat representation by replacing module instantiations with their internal components and resolving all interconnections accordingly.[33] This process transforms the structured, modular description into a single-level netlist containing only primitive elements, such as gates or transistors, to facilitate subsequent analyses that require a non-hierarchical view.[33] The algorithm for unfolding typically employs a depth-first traversal of the hierarchy tree, starting from the top-level module and recursively visiting each instantiation. During traversal, components within submodules are duplicated at the parent level, and nets are renamed to prevent conflicts by prefixing them with the instance path (e.g., appending "/instance_name" to net identifiers like "clk" becoming "/u1/clk").[34] This duplication ensures complete connectivity resolution, while parameter handling involves substituting module-specific values (e.g., widths or delays) into the expanded primitives before integration.[35] To optimize, caching mechanisms may store previously processed submodule data, appending path segments rather than fully recomputing for identical instances, though full unfolding requires explicit replication for accuracy in simulation contexts.[34] In electronic design automation (EDA) tools, unfolding is essential for flat simulation, where hierarchical boundaries can complicate event-driven processing, and for timing analysis, which benefits from a unified graph of delays and paths without recursive lookups.[35] Parameter substitution during unfolding allows tools to evaluate instance-specific behaviors, such as varying transistor sizes, directly in the flat structure.[35] A key limitation of unfolding is the potential for exponential growth in netlist size, particularly in deep hierarchies with high fanout, as each instantiation duplicates submodule contents, leading to millions of additional elements in large designs.[36] This can increase memory usage and processing time, complicating debugging and verification; mitigation strategies include partial unfolding, where only selected submodules are expanded to balance detail and manageability.[36] For example, consider a hierarchical netlist for a D flip-flop module (DFF) instantiated within a top-level counter (COUNTER), where DFF contains internal gates like AND, NAND, and inverters connected via nets such as "d_in," "clk," and "q_out." In the unfolded flat netlist, the DFF instantiation is replaced by duplicating its gates (prefixed as "u_dff/and1," "u_dff/nand2," etc.), with connections resolved: the original "clk" net in COUNTER now links directly to all prefixed clock inputs in the duplicated gates, and "q_out" becomes "u_dff/q_out" wired to the counter's output logic, eliminating all module boundaries.[34]Back-Annotation
Back-annotation is the process of updating a logical netlist with parasitic elements, such as resistance and capacitance, extracted from the post-layout geometry of an integrated circuit to enable more accurate simulations that reflect actual silicon behavior.[37] This technique propagates physical layout data, including interconnect delays and coupling effects, back into the original design representation for post-layout verification.[37] The process begins with extracting parasitics from the layout using tools like HIPEX in EDA flows, followed by mapping physical nets to logical ones through name correspondence derived from layout-versus-schematic (LVS) matching reports or, in some cases, geometric alignment of components.[37] Once mapped, RC models representing these parasitics—such as lumped or distributed elements—are inserted into the netlist, often splitting nets (e.g., a single net into sub-nets like NET12:17 and NET12:25) to incorporate the extracted values.[37] In place-and-route workflows, this integration commonly uses formats like the Standard Parasitic Exchange Format (SPEF), an IEEE standard (IEEE 1481-1999) for ASCII-based exchange of resistance, capacitance, and inductance data between EDA tools. Back-annotation is essential in electronic design automation (EDA) for performing precise timing and power analysis after routing, as it accounts for layout-induced effects that ideal logical simulations overlook.[37] In hierarchical netlists, the process supports annotation at multiple levels, allowing parasitics to be applied to subcircuits without fully flattening the design, which preserves modularity and reduces computational overhead during simulation.[38] For example, in a gate-level netlist for a shift register circuit, wire delays and capacitances extracted from the laid-out design can be back-annotated using SPEF data to update the simulation model for verifying post-layout performance.[37]Inheritance
Inheritance in hierarchical netlists refers to the technique where child instances automatically acquire attributes—such as parameters, timing models, and connectivity properties—from their defining parent modules, with provisions for local overrides to customize behavior without altering the base definition. This mechanism promotes reuse by avoiding explicit replication of shared properties across instances, ensuring consistency while allowing flexibility for design variations.[39][40] Implementation typically involves parameter passing during module instantiation in hardware description languages like Verilog, where defaults defined in the parent module (e.g.,parameter DELAY = 1.0;) can be overridden via syntax such as module_instance #( .DELAY(2.0) ) (ports);. For library-based inheritance, standard cell libraries employ type-variants that derive from base cells, inheriting core attributes like transistor sizing while adjusting parameters for variants such as different drive strengths or voltage thresholds; this is common in processes where extracted netlists use clustering algorithms to map instances to these variants. Inherited connections, particularly for power and ground nets, are realized through properties like net expressions and netSet overrides, enabling implicit propagation from higher to lower hierarchy levels without dedicated pins in sub-schematics.[39][40][41]
The primary benefits include significant reductions in netlist file size—up to 70% in some verification flows—by eliminating redundant attribute specifications, alongside simplified maintenance for configurable designs like parameterized logic gates that adapt to varying process conditions. This approach also facilitates scalable analysis, as inherited properties streamline timing and power evaluations across large hierarchies.[40]
Challenges arise in conflict resolution for overrides propagated through multiple hierarchy levels, where ambiguous or cascading changes may lead to inconsistent effective values unless governed by strict propagation rules; additionally, verifying inherited properties, such as ensuring timing models accurately reflect combined overrides, requires specialized tools to trace and validate parameter resolution without introducing errors. The proliferation of variants can also inflate library complexity, increasing memory demands during hierarchy recovery.[40]
A representative example occurs in a digital netlist featuring a base inverter module with a default propagation delay parameter; multiple instances inherit this delay for baseline performance, but local overrides adjust it based on fanout load—e.g., increasing the value for high-fanout paths to model realistic slew rates—thus enabling efficient reuse while tailoring to contextual electrical characteristics.[39]