364 lines
19 KiB
HTML
364 lines
19 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<html lang="en" data-content_root="../../../">
|
||
<head>
|
||
<meta charset="utf-8" />
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
|
||
|
||
<title>Netlist Format — Icarus Verilog documentation</title>
|
||
<link rel="stylesheet" type="text/css" href="../../../_static/pygments.css?v=fa44fd50" />
|
||
<link rel="stylesheet" type="text/css" href="../../../_static/alabaster.css?v=cb25574f" />
|
||
<script src="../../../_static/documentation_options.js?v=5929fcd5"></script>
|
||
<script src="../../../_static/doctools.js?v=888ff710"></script>
|
||
<script src="../../../_static/sphinx_highlight.js?v=dc90522c"></script>
|
||
<link rel="icon" href="../../../_static/favicon.ico"/>
|
||
<link rel="index" title="Index" href="../../../genindex.html" />
|
||
<link rel="search" title="Search" href="../../../search.html" />
|
||
<link rel="next" title="Icarus Verilog Attributes" href="attributes.html" />
|
||
<link rel="prev" title="IVL - The Core Compiler" href="index.html" />
|
||
|
||
<link rel="stylesheet" href="../../../_static/custom.css" type="text/css" />
|
||
|
||
|
||
<meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
|
||
|
||
</head><body>
|
||
|
||
|
||
<div class="document">
|
||
<div class="documentwrapper">
|
||
<div class="bodywrapper">
|
||
|
||
|
||
<div class="body" role="main">
|
||
|
||
<section id="netlist-format">
|
||
<h1>Netlist Format<a class="headerlink" href="#netlist-format" title="Link to this heading">¶</a></h1>
|
||
<p>The output from the parse and elaboration steps is a “netlist” rooted
|
||
in a Design object. Parsing translates the design described in the
|
||
initial source file into a temporary symbolic “pform”. Elaboration
|
||
then expands the design, resolving references and expanding
|
||
hierarchies, to produce a flattened netlist. This is the form that
|
||
optimizers and code generators use.</p>
|
||
<p>The design optimization processes all manipulate the netlist,
|
||
translating it to a (hopefully) better netlist after each step. The
|
||
complete netlist is then passed to the code generator, the emit
|
||
function, where the final code (in the target format) is produced.</p>
|
||
<section id="structural-items-netnode-and-netnet">
|
||
<h2>Structural Items: NetNode and NetNet<a class="headerlink" href="#structural-items-netnode-and-netnet" title="Link to this heading">¶</a></h2>
|
||
<p>Components and wires, memories and registers all at their base are
|
||
either NetNode objects or NetNet objects. Even these classes are
|
||
derived from the NetObj class.</p>
|
||
<p>All NetNode and NetNet objects have a name and some number of
|
||
pins. The name usually comes from the Verilog source that represents
|
||
that object, although objects that are artifacts of elaboration will
|
||
have a generated (and probably unreadable) name. The pins are the
|
||
ports into the device. NetNode objects have a pin for each pin of the
|
||
component it represents, and NetNet objects have a pin for each signal
|
||
in the vector.</p>
|
||
<p>Node and net pins can be connected together via the connect
|
||
function. Connections are transitive (A==B and B==c means A==C) so
|
||
connections accumulate on a link as items are connected to it. The
|
||
destructors for nets and nodes automatically arrange for pins to be
|
||
disconnected when the item is deleted, so that the netlist can be
|
||
changed during processing.</p>
|
||
</section>
|
||
<section id="structural-links">
|
||
<h2>Structural Links<a class="headerlink" href="#structural-links" title="Link to this heading">¶</a></h2>
|
||
<p>The NetNode and NetNet classes contain arrays of Link objects, one
|
||
object per pin. Each pin is a single bit. The Link objects link to all
|
||
the NetNode and NetNet objects’ links that are connected together in
|
||
the design, and to a Nexus object. This way, code that examines a node
|
||
of the design can discover what is connected to each pin.</p>
|
||
<p>The connected set of links also has common properties that are stored
|
||
or access from the Nexus object. All the Links that are connected
|
||
together are also connected to a single Nexus object. This object is
|
||
useful for accessing the properties and values that come from the
|
||
connected set of links. The Nexus object is also handy for iterating
|
||
over the connected set of Links.</p>
|
||
<p>See the Link class definition in netlist.h for a description of the link
|
||
methods, and the Nexus class for nexus global methods.</p>
|
||
<p>Currently, a link has 3 possible direction properties:</p>
|
||
<blockquote>
|
||
<div><dl class="simple">
|
||
<dt>PASSIVE – These pins are sampled by the object that holds the</dt><dd><p>pin based on some external event. These are used,
|
||
for example, by NetESignal objects that read a
|
||
point for a procedural expression.</p>
|
||
</dd>
|
||
<dt>INPUT – These pins potentially react to the setting of its</dt><dd><p>input.</p>
|
||
</dd>
|
||
<dt>OUTPUT – These pins potentially drive the node. (They may be</dt><dd><p>three-state.)</p>
|
||
</dd>
|
||
</dl>
|
||
</div></blockquote>
|
||
</section>
|
||
<section id="behavioral-items-netproctop-netproc-and-derived-classes">
|
||
<h2>Behavioral Items: NetProcTop, NetProc and derived classes<a class="headerlink" href="#behavioral-items-netproctop-netproc-and-derived-classes" title="Link to this heading">¶</a></h2>
|
||
<p>Behavioral items are not in general linked to the netlist. Instead,
|
||
they represent elaborated behavioral statements. The type of the object
|
||
implies what the behavior of the statement does. For example, a
|
||
NetCondit object represents an <cite>if</cite> statement, and carries a
|
||
condition expression and up to two alternative sub-statements.</p>
|
||
<p>At the root of a process is a NetProcTop object. This class carries a
|
||
type flag (initial or always) and a single NetProc object. The
|
||
contained statement may, depending on the derived class, refer to
|
||
other statements, compound statements, so on. But at the root of the
|
||
tree is the NetProcTop object. The Design class keeps a list of the
|
||
elaborated NetProcTop objects. That list represents the list of
|
||
processes in the design.</p>
|
||
</section>
|
||
<section id="interaction-of-behavioral-and-structural-netassign">
|
||
<h2>Interaction Of Behavioral And Structural: NetAssign_<a class="headerlink" href="#interaction-of-behavioral-and-structural-netassign" title="Link to this heading">¶</a></h2>
|
||
<p>The behavioral statements in a Verilog design effect the structural
|
||
aspects through assignments to registers. Registers are structural
|
||
items represented by the NetNet class, linked to the assignment
|
||
statement through pins. This implies that the l-value of an assignment
|
||
is structural. It also implies that the statement itself is
|
||
structural, and indeed it is derived from NetNode.</p>
|
||
<p>The NetAssign_ class is also derived from the NetProc class because
|
||
what it does is brought on by executing the process. By multiple
|
||
inheritance we have therefore that the assignment is both a NetNode
|
||
and a NetProc. The NetAssign_ node has pins that represent the l-value
|
||
of the statement, and carries behavioral expressions that represent
|
||
the r-value of the assignment.</p>
|
||
</section>
|
||
<section id="memories">
|
||
<h2>Memories<a class="headerlink" href="#memories" title="Link to this heading">¶</a></h2>
|
||
<p>The netlist form includes the NetMemory type to hold the content of a
|
||
memory. Instances of this type represent the declaration of a memory,
|
||
and occur once for each memory. References to the memory are managed
|
||
by the NetEMemory and NetAssignMem_ classes.</p>
|
||
<p>An instance of the NetEMemory class is created whenever a procedural
|
||
expression references a memory element. The operand is the index to
|
||
use to address (and read) the memory.</p>
|
||
<p>An instance of the NetAssignMem_ class is created when there is a
|
||
procedural assignment to the memory. The NetAssignMem_ object
|
||
represents the l-value reference (a write) to the memory. As with the
|
||
NetEMemory class, this is a procedural reference only.</p>
|
||
<p>When a memory reference appears in structural context (i.e. continuous
|
||
assignments) elaboration creates a NetRamDq. This is a LPM_RAM_DQ
|
||
device. Elaboration leaves the write control and data input pins
|
||
unconnected for now, because memories cannot appear is l-values of
|
||
continuous assignments. However, the synthesis functor may connect
|
||
signals to the write control lines to get a fully operational RAM.</p>
|
||
<p>By the time elaboration completes, there may be many NetAssignMem_,
|
||
NetEMemory and NetRamDq objects referencing the same NetMemory
|
||
object. Each represents a port into the memory. It is up to the
|
||
synthesis steps (and the target code) to figure out what to do with
|
||
these ports.</p>
|
||
</section>
|
||
<section id="expressions">
|
||
<h2>Expressions<a class="headerlink" href="#expressions" title="Link to this heading">¶</a></h2>
|
||
<p>Expressions are represented as a tree of NetExpr nodes. The NetExpr
|
||
base class contains the core methods that represent an expression
|
||
node, including virtual methods to help with dealing with nested
|
||
complexities of expressions.</p>
|
||
<p>Expressions (as expressed in the source and p-form) may also be
|
||
elaborated structurally, where it makes sense. For example, assignment
|
||
l-value expressions are represented as connections to pins. Also,
|
||
continuous assignment module items are elaborated as gates instead of
|
||
as a procedural expression. Event expressions are also elaborated
|
||
structurally as events are like devices that trigger behavioral
|
||
statements.</p>
|
||
<p>However, typical expressions the behavioral description are
|
||
represented as a tree of NetExpr nodes. The derived class of the node
|
||
encodes what kind of operator the node represents.</p>
|
||
</section>
|
||
<section id="expression-bit-width">
|
||
<h2>Expression Bit Width<a class="headerlink" href="#expression-bit-width" title="Link to this heading">¶</a></h2>
|
||
<p>The expression (represented by the NetExpr class) has a bit width that
|
||
it either explicitly specified, or implied by context or contents.
|
||
When each node of the expression is first constructed during
|
||
elaboration, it is given, by type and parameters, an idea what its
|
||
width should be. It certain cases, this is definitive, for example
|
||
with signals. In others, it is ambiguous, as with unsized constants.</p>
|
||
<p>As the expression is built up by elaboration, operators that combine
|
||
expressions impose bit widths of the environment or expose the bit
|
||
widths of the sub expressions. For example, the bitwise AND (&)
|
||
operator has a bit size implied by its operands, whereas the
|
||
comparison (==) operator has a bit size of 1. The building up of the
|
||
elaborated expression checks and adjusts the bit widths as the
|
||
expression is built up, until finally the context of the expression
|
||
takes the final bit width and makes any final adjustments.</p>
|
||
<p>The NetExpr::expr_width() method returns the calculated (or guessed)
|
||
expression width. This method will return 0 until the width is set by
|
||
calculation or context. If this method returns false, then it is up to
|
||
the context that wants the width to set one. The elaboration phase
|
||
will call the NetExpr::set_width method on an expression as soon as it
|
||
gets to a point where it believes that it knows what the width should
|
||
be.</p>
|
||
<p>The NetExpr::set_width(unsigned) virtual method is used by the context
|
||
of an expression node to note to the expression that the width is
|
||
determined and please adapt. If the expression cannot reasonably
|
||
adapt, it will return false. Otherwise, it will adjust bit widths and
|
||
return true.</p>
|
||
<div class="highlight-none notranslate"><div class="highlight"><pre><span></span>I do not yet properly deal with cases where elaboration knows for
|
||
certain that the bit width does not matter. In this case, I
|
||
really should tell the expression node about it so that it can
|
||
pick a practical (and optimal) width.
|
||
</pre></div>
|
||
</div>
|
||
</section>
|
||
<section id="interaction-of-expressions-and-structure-netesignal">
|
||
<h2>Interaction Of Expressions And Structure: NetESignal<a class="headerlink" href="#interaction-of-expressions-and-structure-netesignal" title="Link to this heading">¶</a></h2>
|
||
<p>The NetAssign_ class described above is the means for processes to
|
||
manipulate the net, but values are read from the net by NetESignal
|
||
objects. These objects are class NetExpr because they can appear in
|
||
expressions (and have width). They are not NetNode object, but hold
|
||
pointers to a NetNet object, which is used to retrieve values with the
|
||
expression is evaluated.</p>
|
||
</section>
|
||
<section id="hierarchy-in-netlists">
|
||
<h2>Hierarchy In Netlists<a class="headerlink" href="#hierarchy-in-netlists" title="Link to this heading">¶</a></h2>
|
||
<p>The obvious hierarchical structure of Verilog is the module. The
|
||
Verilog program may contain any number of instantiations of modules in
|
||
order to form an hierarchical design. However, the elaboration of the
|
||
design into a netlist erases module boundaries. Modules are expanded
|
||
each place they are used, with the hierarchical instance name used to
|
||
name the components of the module instance. However, the fact that a
|
||
wire or register is a module port is lost.</p>
|
||
<p>The advantage of this behavior is first the simplification of the
|
||
netlist structure itself. Backends that process netlists only need to
|
||
cope with a list of nets, a list of nodes and a list of
|
||
processes. This eases the task of the backend code generators.</p>
|
||
<p>Another advantage of this flattening of the netlist is that optimizers
|
||
can operate globally, with optimizations freely crossing module
|
||
boundaries. This makes coding of netlist transform functions such as
|
||
constant propagation more effective and easier to write.</p>
|
||
</section>
|
||
<section id="scope-representation-in-netlists">
|
||
<h2>Scope Representation In Netlists<a class="headerlink" href="#scope-representation-in-netlists" title="Link to this heading">¶</a></h2>
|
||
<p>In spite of the literal flattening of the design, scope information is
|
||
preserved in the netlist, with the NetScope class. The Design class
|
||
keeps a single pointer to the root scope of the design. This is the
|
||
scope of the root module. Scopes that are then created within that
|
||
(or any nested) module are placed as children of the root scope, and
|
||
those children can have further children, and so on.</p>
|
||
<p>Each scope in the tree carries its own name, and its relationship to
|
||
its parent and children. This makes it possible to walk the tree of
|
||
scopes. In practice, the walking of the scopes is handled by recursive
|
||
methods.</p>
|
||
<p>Each scope also carries the parameters that are applicable to the
|
||
scope itself. The parameter expression (possibly evaluated) can be
|
||
located by name, given the scope object itself. The scan of the pform
|
||
to generate scopes also places the parameters that are declared in the
|
||
scope. Overrides are managed during the scan, and once the scan is
|
||
complete, defparam overrides are applied.</p>
|
||
</section>
|
||
<section id="tasks-in-netlists">
|
||
<h2>Tasks In Netlists<a class="headerlink" href="#tasks-in-netlists" title="Link to this heading">¶</a></h2>
|
||
<p>The flattening of the design does not include tasks and named
|
||
begin-end blocks. Tasks are behavioral hierarchy (whereas modules are
|
||
structural) so do not easily succumb to the flattening process. In
|
||
particular, it is logically impossible to flatten tasks that
|
||
recurse. (The elaboration process does reserve the right to flatten
|
||
some task calls. C++ programmers recognize this as inlining a task.)</p>
|
||
</section>
|
||
<section id="time-scale-in-netlists">
|
||
<h2>Time Scale In Netlists<a class="headerlink" href="#time-scale-in-netlists" title="Link to this heading">¶</a></h2>
|
||
<p>The Design class and the NetScope classes carry time scale and
|
||
resolution information of the elaborated design. There is a global
|
||
resolution, and there are scope specific units and resolutions. Units
|
||
and resolutions are specified as signed integers, and interpreted as
|
||
the power of 10 of the value. For example, a resolution “-9” means
|
||
that “1” is 1ns (1e-9). The notation supports units from -128 to +127.
|
||
It is up to the back-ends to interpret “-4” as “100us”.</p>
|
||
<p>Delays are expressed in the netlist by integers. The units of these
|
||
delays are always given in the units of the design precision. This
|
||
allows everything to work with integers, and generally places the
|
||
burden of scaling delays into elaboration. This is, after all, a
|
||
common task. The Design::get_precision() method gets the global design
|
||
precision.</p>
|
||
<p>Each NetScope also carries its local time_units and time_precision
|
||
values. These are filled in during scope elaboration and are used in
|
||
subsequent elaboration phases to arrange for scaling of delays. This
|
||
information can also be used by the code generator to scale times back
|
||
to the units of the scope, if that is desired.</p>
|
||
</section>
|
||
</section>
|
||
|
||
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
<div class="sphinxsidebar" role="navigation" aria-label="main navigation">
|
||
<div class="sphinxsidebarwrapper">
|
||
<h1 class="logo"><a href="../../../index.html">Icarus Verilog</a></h1>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
<h3>Navigation</h3>
|
||
<p class="caption" role="heading"><span class="caption-text">Contents:</span></p>
|
||
<ul class="current">
|
||
<li class="toctree-l1"><a class="reference internal" href="../../../usage/index.html">Icarus Verilog Usage</a></li>
|
||
<li class="toctree-l1"><a class="reference internal" href="../../../targets/index.html">The Icarus Verilog Targets</a></li>
|
||
<li class="toctree-l1 current"><a class="reference internal" href="../../index.html">Icarus Verilog Developer Support</a><ul class="current">
|
||
<li class="toctree-l2"><a class="reference internal" href="../../getting_started.html">Getting Started as a Contributor</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="../../regression_tests.html">The Regression Test Suite</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="../../version_stamps.html">Files With Version Information</a></li>
|
||
<li class="toctree-l2 current"><a class="reference internal" href="../index.html">Developer Guide</a></li>
|
||
<li class="toctree-l2"><a class="reference internal" href="../../glossary.html">Glossary</a></li>
|
||
</ul>
|
||
</li>
|
||
</ul>
|
||
|
||
<div class="relations">
|
||
<h3>Related Topics</h3>
|
||
<ul>
|
||
<li><a href="../../../index.html">Documentation overview</a><ul>
|
||
<li><a href="../../index.html">Icarus Verilog Developer Support</a><ul>
|
||
<li><a href="../index.html">Developer Guide</a><ul>
|
||
<li><a href="index.html">IVL - The Core Compiler</a><ul>
|
||
<li>Previous: <a href="index.html" title="previous chapter">IVL - The Core Compiler</a></li>
|
||
<li>Next: <a href="attributes.html" title="next chapter">Icarus Verilog Attributes</a></li>
|
||
</ul></li>
|
||
</ul></li>
|
||
</ul></li>
|
||
</ul></li>
|
||
</ul>
|
||
</div>
|
||
<div id="searchbox" style="display: none" role="search">
|
||
<h3 id="searchlabel">Quick search</h3>
|
||
<div class="searchformwrapper">
|
||
<form class="search" action="../../../search.html" method="get">
|
||
<input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
|
||
<input type="submit" value="Go" />
|
||
</form>
|
||
</div>
|
||
</div>
|
||
<script>document.getElementById('searchbox').style.display = "block"</script>
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
</div>
|
||
</div>
|
||
<div class="clearer"></div>
|
||
</div>
|
||
<div class="footer">
|
||
©2024-2025, Stephen Williams.
|
||
|
||
|
|
||
Powered by <a href="http://sphinx-doc.org/">Sphinx 7.2.6</a>
|
||
& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
|
||
|
||
|
|
||
<a href="../../../_sources/developer/guide/ivl/netlist.rst.txt"
|
||
rel="nofollow">Page source</a>
|
||
</div>
|
||
|
||
|
||
|
||
|
||
</body>
|
||
</html> |