verilator/test_regress/t/t_xml_flat.out

116 lines
6.5 KiB
Plaintext
Raw Normal View History

<?xml version="1.0" ?>
<!-- DESCRIPTION: Verilator output: XML representation of netlist -->
<verilator_xml>
<files>
2024-03-02 15:01:37 +01:00
<file id="a" filename="&lt;built-in&gt;" language="1800-2023"/>
<file id="b" filename="&lt;command-line&gt;" language="1800-2023"/>
<file id="c" filename="input.vc" language="1800-2023"/>
<file id="d" filename="t/t_xml_first.v" language="1800-2023"/>
</files>
<module_files>
2024-03-02 15:01:37 +01:00
<file id="d" filename="t/t_xml_first.v" language="1800-2023"/>
</module_files>
<cells>
<cell loc="d,7,8,7,9" name="$root" submodname="$root" hier="$root"/>
</cells>
<netlist>
<module loc="d,7,8,7,9" name="$root" origName="$root" topModule="1" public="true">
<var loc="d,15,22,15,23" name="q" dtype_id="1" dir="output" pinIndex="1" vartype="logic" origName="q" public="true"/>
Deprecate clocker attribute and --clk option (#6463) The only use for the clocker attribute and the AstVar::isUsedClock that is actually necessary today for correctness is to mark top level inputs of --lib-create blocks as being (or driving) a clock signal. Correctness of --lib-create (and hence hierarchical blocks) actually used to depend on having the right optimizations eliminate intermediate clocks (e.g.: V3Gate), when the top level port was not used directly in a sensitivity list, or marking top level signals manually via --clk or the clocker attribute. However V3Sched::partition already needs to trace through the logic to figure out what signals might drive a sensitivity list, so it can very easily mark all top level inputs as such. In this patch we remove the AstVar::attrClocker and AstVar::isUsedClock attributes, and replace them with AstVar::isPrimaryClock, automatically set by V3Sched::partition. This eliminates all need for manual annotation so we are deprecating the --clk/--no-clk options and the clocker/no_clocker attributes. This also eliminates the opportunity for any further mis-optimization similar to #6453. Regarding the other uses of the removed AstVar attributes: - As of 5.000, initial edges are triggered via a separate mechanism applied in V3Sched, so the use in V3EmitCFunc.cpp is redundant - Also as of 5.000, we can handle arbitrary sensitivity expressions, so the restriction on eliminating clock signals in V3Gate is unnecessary - Since the recent change when Dfg is applied after V3Scope, it does perform the equivalent of GateClkDecomp, so we can delete that pass.
2025-09-20 16:50:22 +02:00
<var loc="d,13,10,13,13" name="clk" dtype_id="2" dir="input" pinIndex="2" vartype="logic" origName="clk" public="true"/>
<var loc="d,14,16,14,17" name="d" dtype_id="1" dir="input" pinIndex="3" vartype="logic" origName="d" public="true"/>
<var loc="d,15,22,15,23" name="t.q" dtype_id="1" vartype="logic" origName="q"/>
<var loc="d,13,10,13,13" name="t.clk" dtype_id="2" vartype="logic" origName="clk"/>
<var loc="d,14,16,14,17" name="t.d" dtype_id="1" vartype="logic" origName="d"/>
<var loc="d,17,22,17,29" name="t.between" dtype_id="1" vartype="logic" origName="between"/>
<var loc="d,32,15,32,20" name="t.cell1.WIDTH" dtype_id="3" vartype="logic" origName="WIDTH" param="true">
<const loc="d,19,18,19,19" name="32&apos;sh4" dtype_id="3"/>
</var>
<var loc="d,34,24,34,27" name="t.cell1.clk" dtype_id="2" vartype="logic" origName="clk"/>
<var loc="d,35,30,35,31" name="t.cell1.d" dtype_id="1" vartype="logic" origName="d"/>
<var loc="d,36,30,36,31" name="t.cell1.q" dtype_id="1" vartype="logic" origName="q"/>
<var loc="d,39,15,39,22" name="t.cell1.IGNORED" dtype_id="3" vartype="logic" origName="IGNORED" localparam="true">
<const loc="d,39,25,39,26" name="32&apos;sh1" dtype_id="3"/>
</var>
<var loc="d,48,10,48,13" name="t.cell2.clk" dtype_id="2" vartype="logic" origName="clk"/>
<var loc="d,49,16,49,17" name="t.cell2.d" dtype_id="1" vartype="logic" origName="d"/>
<var loc="d,50,22,50,23" name="t.cell2.q" dtype_id="1" vartype="logic" origName="q"/>
<topscope loc="d,7,8,7,9">
<scope loc="d,7,8,7,9" name="TOP">
<varscope loc="d,15,22,15,23" name="q" dtype_id="1"/>
<varscope loc="d,13,10,13,13" name="clk" dtype_id="2"/>
<varscope loc="d,14,16,14,17" name="d" dtype_id="1"/>
<varscope loc="d,15,22,15,23" name="t.q" dtype_id="1"/>
<varscope loc="d,13,10,13,13" name="t.clk" dtype_id="2"/>
<varscope loc="d,14,16,14,17" name="t.d" dtype_id="1"/>
<varscope loc="d,17,22,17,29" name="t.between" dtype_id="1"/>
<varscope loc="d,32,15,32,20" name="t.cell1.WIDTH" dtype_id="3"/>
<varscope loc="d,34,24,34,27" name="t.cell1.clk" dtype_id="2"/>
<varscope loc="d,35,30,35,31" name="t.cell1.d" dtype_id="1"/>
<varscope loc="d,36,30,36,31" name="t.cell1.q" dtype_id="1"/>
<varscope loc="d,39,15,39,22" name="t.cell1.IGNORED" dtype_id="3"/>
<varscope loc="d,48,10,48,13" name="t.cell2.clk" dtype_id="2"/>
<varscope loc="d,49,16,49,17" name="t.cell2.d" dtype_id="1"/>
<varscope loc="d,50,22,50,23" name="t.cell2.q" dtype_id="1"/>
<assignalias loc="d,15,22,15,23" dtype_id="1">
<varref loc="d,15,22,15,23" name="q" dtype_id="1"/>
<varref loc="d,15,22,15,23" name="t.q" dtype_id="1"/>
</assignalias>
<assignalias loc="d,13,10,13,13" dtype_id="2">
<varref loc="d,13,10,13,13" name="clk" dtype_id="2"/>
<varref loc="d,13,10,13,13" name="t.clk" dtype_id="2"/>
</assignalias>
<assignalias loc="d,14,16,14,17" dtype_id="1">
<varref loc="d,14,16,14,17" name="d" dtype_id="1"/>
<varref loc="d,14,16,14,17" name="t.d" dtype_id="1"/>
</assignalias>
<assignalias loc="d,36,30,36,31" dtype_id="1">
<varref loc="d,20,14,20,21" name="t.between" dtype_id="1"/>
<varref loc="d,36,30,36,31" name="t.cell1.q" dtype_id="1"/>
</assignalias>
<assignalias loc="d,34,24,34,27" dtype_id="2">
<varref loc="d,21,42,21,45" name="t.clk" dtype_id="2"/>
<varref loc="d,34,24,34,27" name="t.cell1.clk" dtype_id="2"/>
</assignalias>
<assignalias loc="d,35,30,35,31" dtype_id="1">
<varref loc="d,22,42,22,43" name="t.d" dtype_id="1"/>
<varref loc="d,35,30,35,31" name="t.cell1.d" dtype_id="1"/>
</assignalias>
<always loc="d,41,4,41,10">
<sentree loc="d,41,11,41,12">
<senitem loc="d,41,13,41,20" edgeType="POS">
<varref loc="d,41,21,41,24" name="clk" dtype_id="2"/>
</senitem>
</sentree>
<assigndly loc="d,42,8,42,10" dtype_id="1">
<varref loc="d,42,11,42,12" name="d" dtype_id="1"/>
<varref loc="d,42,6,42,7" name="t.between" dtype_id="1"/>
</assigndly>
</always>
<assignalias loc="d,49,16,49,17" dtype_id="1">
<varref loc="d,25,16,25,23" name="t.between" dtype_id="1"/>
<varref loc="d,49,16,49,17" name="t.cell2.d" dtype_id="1"/>
</assignalias>
<assignalias loc="d,50,22,50,23" dtype_id="1">
<varref loc="d,26,42,26,43" name="t.q" dtype_id="1"/>
<varref loc="d,50,22,50,23" name="t.cell2.q" dtype_id="1"/>
</assignalias>
<assignalias loc="d,48,10,48,13" dtype_id="2">
<varref loc="d,27,42,27,45" name="t.clk" dtype_id="2"/>
<varref loc="d,48,10,48,13" name="t.cell2.clk" dtype_id="2"/>
</assignalias>
<contassign loc="d,53,13,53,14" dtype_id="1">
Introduce DFG based combinational logic optimizer (#3527) Added a new data-flow graph (DFG) based combinational logic optimizer. The capabilities of this covers a combination of V3Const and V3Gate, but is also more capable of transforming combinational logic into simplified forms and more. This entail adding a new internal representation, `DfgGraph`, and appropriate `astToDfg` and `dfgToAst` conversion functions. The graph represents some of the combinational equations (~continuous assignments) in a module, and for the duration of the DFG passes, it takes over the role of AstModule. A bulk of the Dfg vertices represent expressions. These vertex classes, and the corresponding conversions to/from AST are mostly auto-generated by astgen, together with a DfgVVisitor that can be used for dynamic dispatch based on vertex (operation) types. The resulting combinational logic graph (a `DfgGraph`) is then optimized in various ways. Currently we perform common sub-expression elimination, variable inlining, and some specific peephole optimizations, but there is scope for more optimizations in the future using the same representation. The optimizer is run directly before and after inlining. The pre inline pass can operate on smaller graphs and hence converges faster, but still has a chance of substantially reducing the size of the logic on some designs, making inlining both faster and less memory intensive. The post inline pass can then optimize across the inlined module boundaries. No optimization is performed across a module boundary. For debugging purposes, each peephole optimization can be disabled individually via the -fno-dfg-peepnole-<OPT> option, where <OPT> is one of the optimizations listed in V3DfgPeephole.h, for example -fno-dfg-peephole-remove-not-not. The peephole patterns currently implemented were mostly picked based on the design that inspired this work, and on that design the optimizations yields ~30% single threaded speedup, and ~50% speedup on 4 threads. As you can imagine not having to haul around redundant combinational networks in the rest of the compilation pipeline also helps with memory consumption, and up to 30% peak memory usage of Verilator was observed on the same design. Gains on other arbitrary designs are smaller (and can be improved by analyzing those designs). For example OpenTitan gains between 1-15% speedup depending on build type.
2022-09-23 17:46:22 +02:00
<varref loc="d,17,22,17,29" name="t.between" dtype_id="1"/>
<varref loc="d,53,13,53,14" name="q" dtype_id="1"/>
</contassign>
</scope>
</topscope>
</module>
<typetable loc="a,0,0,0,0">
<basicdtype loc="d,34,24,34,27" id="2" name="logic"/>
<basicdtype loc="d,15,16,15,17" id="1" name="logic" left="3" right="0"/>
<basicdtype loc="d,19,18,19,19" id="3" name="logic" left="31" right="0" signed="true"/>
<voiddtype loc="a,0,0,0,0" id="4"/>
</typetable>
</netlist>
</verilator_xml>