2020-04-22 00:14:08 +02:00
|
|
|
<?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="<built-in>" language="1800-2023"/>
|
|
|
|
|
<file id="b" filename="<command-line>" language="1800-2023"/>
|
|
|
|
|
<file id="c" filename="input.vc" language="1800-2023"/>
|
|
|
|
|
<file id="d" filename="t/t_xml_first.v" language="1800-2023"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</files>
|
|
|
|
|
<module_files>
|
2024-03-02 15:01:37 +01:00
|
|
|
<file id="d" filename="t/t_xml_first.v" language="1800-2023"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</module_files>
|
|
|
|
|
<cells>
|
2022-01-17 22:22:07 +01:00
|
|
|
<cell loc="d,7,8,7,9" name="$root" submodname="$root" hier="$root"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</cells>
|
|
|
|
|
<netlist>
|
2022-01-17 22:22:07 +01:00
|
|
|
<module loc="d,7,8,7,9" name="$root" origName="$root" topModule="1" public="true">
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2022-01-17 22:22:07 +01:00
|
|
|
<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'sh4" dtype_id="3"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</var>
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2022-01-17 22:22:07 +01:00
|
|
|
<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'sh1" dtype_id="3"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</var>
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2022-01-17 22:22:07 +01:00
|
|
|
<topscope loc="d,7,8,7,9">
|
|
|
|
|
<scope loc="d,7,8,7,9" name="TOP">
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,15,22,15,23">
|
|
|
|
|
<contassign 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"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,13,10,13,13" name="t.clk" dtype_id="2"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,13,10,13,13">
|
|
|
|
|
<contassign 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"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,14,16,14,17" name="t.d" dtype_id="1"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,14,16,14,17">
|
|
|
|
|
<contassign 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"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<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"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,34,24,34,27">
|
|
|
|
|
<contassign loc="d,34,24,34,27" dtype_id="2">
|
|
|
|
|
<varref loc="d,34,24,34,27" name="clk" dtype_id="2"/>
|
|
|
|
|
<varref loc="d,34,24,34,27" name="t.cell1.clk" dtype_id="2"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,35,30,35,31" name="t.cell1.d" dtype_id="1"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,35,30,35,31">
|
|
|
|
|
<contassign loc="d,35,30,35,31" dtype_id="1">
|
|
|
|
|
<varref loc="d,35,30,35,31" name="d" dtype_id="1"/>
|
|
|
|
|
<varref loc="d,35,30,35,31" name="t.cell1.d" dtype_id="1"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,36,30,36,31" name="t.cell1.q" dtype_id="1"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,36,30,36,31">
|
|
|
|
|
<contassign loc="d,36,30,36,31" dtype_id="1">
|
|
|
|
|
<varref loc="d,36,30,36,31" name="t.between" dtype_id="1"/>
|
|
|
|
|
<varref loc="d,36,30,36,31" name="t.cell1.q" dtype_id="1"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<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"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,48,10,48,13">
|
|
|
|
|
<contassign loc="d,48,10,48,13" dtype_id="2">
|
|
|
|
|
<varref loc="d,48,10,48,13" name="clk" dtype_id="2"/>
|
|
|
|
|
<varref loc="d,48,10,48,13" name="t.cell2.clk" dtype_id="2"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,49,16,49,17" name="t.cell2.d" dtype_id="1"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,49,16,49,17">
|
|
|
|
|
<contassign loc="d,49,16,49,17" dtype_id="1">
|
|
|
|
|
<varref loc="d,49,16,49,17" name="t.between" dtype_id="1"/>
|
|
|
|
|
<varref loc="d,49,16,49,17" name="t.cell2.d" dtype_id="1"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2025-09-26 15:19:48 +02:00
|
|
|
<varscope loc="d,50,22,50,23" name="t.cell2.q" dtype_id="1"/>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,50,22,50,23">
|
|
|
|
|
<contassign loc="d,50,22,50,23" dtype_id="1">
|
|
|
|
|
<varref loc="d,50,22,50,23" name="q" dtype_id="1"/>
|
|
|
|
|
<varref loc="d,50,22,50,23" name="t.cell2.q" dtype_id="1"/>
|
|
|
|
|
</contassign>
|
|
|
|
|
</always>
|
2022-01-17 22:22:07 +01:00
|
|
|
<always loc="d,41,4,41,10">
|
|
|
|
|
<sentree loc="d,41,11,41,12">
|
|
|
|
|
<senitem loc="d,41,13,41,20" edgeType="POS">
|
2022-09-01 00:12:14 +02:00
|
|
|
<varref loc="d,41,21,41,24" name="clk" dtype_id="2"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</senitem>
|
|
|
|
|
</sentree>
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</assigndly>
|
|
|
|
|
</always>
|
Internals: Make AstAssignW a procedural statement (#6280) (#6556)
Initial idea was to remodel AssignW as Assign under Alway. Trying that
uncovered some issues, the most difficult of them was that a delay
attached to a continuous assignment behaves differently from a delay
attached to a blocking assignment statement, so we need to keep the
knowledge of which flavour an assignment was until V3Timing.
So instead of removing AstAssignW, we always wrap it in an AstAlways,
with a special `keyword()` type. This makes it into a proper procedural
statement, which is almost equivalent to AstAssign, except for the case
when they contain a delay. We still gain the benefits of #6280 and can
simplify some code. Every AstNodeStmt should now be under an
AstNodeProcedure - which we should rename to AstProcess, or an
AstNodeFTask). As a result, V3Table can now handle AssignW for free.
Also uncovered and fixed a bug in handling intra-assignment delays if
a function is present on the RHS of an AssignW.
There is more work to be done towards #6280, and potentially simplifying
AssignW handing, but this is the minimal change required to tick it off
the TODO list for #6280.
2025-10-14 10:05:19 +02:00
|
|
|
<always loc="d,53,13,53,14">
|
|
|
|
|
<contassign loc="d,53,13,53,14" dtype_id="1">
|
|
|
|
|
<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>
|
|
|
|
|
</always>
|
2020-04-22 00:14:08 +02:00
|
|
|
</scope>
|
|
|
|
|
</topscope>
|
|
|
|
|
</module>
|
2022-01-17 22:22:07 +01:00
|
|
|
<typetable loc="a,0,0,0,0">
|
2022-09-01 00:12:14 +02:00
|
|
|
<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"/>
|
2022-01-17 22:22:07 +01:00
|
|
|
<basicdtype loc="d,19,18,19,19" id="3" name="logic" left="31" right="0" signed="true"/>
|
2025-09-07 21:38:50 +02:00
|
|
|
<voiddtype loc="a,0,0,0,0" id="4"/>
|
2020-04-22 00:14:08 +02:00
|
|
|
</typetable>
|
|
|
|
|
</netlist>
|
|
|
|
|
</verilator_xml>
|
