luke
/
verilator
mirror of https://github.com/verilator/verilator.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
verilator/test_regress/t/t_dump_json.out

1771 lines
122 KiB
Plaintext
Raw Normal View History

Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"NETLIST","name":"$root","addr":"(B)","loc":"a,0:0,0:0","timeunit":"1ps","timeprecision":"1ps","typeTablep":"(C)","constPoolp":"(D)","dollarUnitPkgp":"(E)","stdPackagep":"(F)","evalp":"UNLINKED","evalNbap":"UNLINKED","dpiExportTriggerp":"UNLINKED","delaySchedulerp":"UNLINKED","nbaEventp":"UNLINKED","nbaEventTriggerp":"UNLINKED","topScopep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"modulesp": [
Support generic interfaces (#6272)
2025-08-22 12:44:35 +02:00
{"type":"MODULE","name":"t","addr":"(G)","loc":"e,7:8,7:9","isChecker":false,"isProgram":false,"hasGenericIface":false,"origName":"t","level":2,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"1ps","inlinesp": [],
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"PORT","name":"clk","addr":"(H)","loc":"e,9:4,9:7","exprp": []},
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
{"type":"VAR","name":"clk","addr":"(I)","loc":"e,11:10,11:13","dtypep":"UNLINKED","origName":"clk","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"LOGIC_IMPLICIT","addr":"(J)","loc":"e,11:10,11:13","dtypep":"(J)","keyword":"LOGIC_IMPLICIT","generic":false,"rangep": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"cyc","addr":"(K)","loc":"e,13:12,13:15","dtypep":"UNLINKED","origName":"cyc","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"integer","addr":"(L)","loc":"e,13:4,13:11","dtypep":"(L)","keyword":"integer","range":"31:0","generic":false,"rangep": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"delayp": [],
"valuep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh0","addr":"(M)","loc":"e,13:18,13:19","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"attrsp": []},
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
{"type":"VAR","name":"crc","addr":"(O)","loc":"e,14:15,14:18","dtypep":"UNLINKED","origName":"crc","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(P)","loc":"e,14:4,14:7","dtypep":"(P)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
Add error on zero/negative unpacked dimensions (#1642).
2025-09-21 15:41:58 +02:00
{"type":"RANGE","name":"","addr":"(Q)","loc":"e,14:8,14:9","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh3f","addr":"(R)","loc":"e,14:9,14:11","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh0","addr":"(T)","loc":"e,14:12,14:13","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"sum","addr":"(U)","loc":"e,15:15,15:18","dtypep":"UNLINKED","origName":"sum","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(V)","loc":"e,15:4,15:7","dtypep":"(V)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
Add error on zero/negative unpacked dimensions (#1642).
2025-09-21 15:41:58 +02:00
{"type":"RANGE","name":"","addr":"(W)","loc":"e,15:8,15:9","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh3f","addr":"(X)","loc":"e,15:9,15:11","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh0","addr":"(Y)","loc":"e,15:12,15:13","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"in","addr":"(Z)","loc":"e,18:16,18:18","dtypep":"UNLINKED","origName":"in","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"WIRE","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(AB)","loc":"e,18:9,18:10","dtypep":"(AB)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
Add error on zero/negative unpacked dimensions (#1642).
2025-09-21 15:41:58 +02:00
{"type":"RANGE","name":"","addr":"(BB)","loc":"e,18:9,18:10","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh1f","addr":"(CB)","loc":"e,18:10,18:12","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"CONST","name":"?32?sh0","addr":"(EB)","loc":"e,18:13,18:14","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"ALWAYS","name":"","addr":"(FB)","loc":"e,18:19,18:20","keyword":"cont_assign","isSuspendable":false,"needProcess":false,"sentreep": [],
"stmtsp": [
{"type":"ASSIGNW","name":"","addr":"(GB)","loc":"e,18:19,18:20","dtypep":"UNLINKED",
"rhsp": [
{"type":"SELEXTRACT","name":"","addr":"(HB)","loc":"e,18:24,18:25","dtypep":"UNLINKED",
"fromp": [
{"type":"PARSEREF","name":"crc","addr":"(IB)","loc":"e,18:21,18:24","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
],
"leftp": [
{"type":"CONST","name":"?32?sh1f","addr":"(JB)","loc":"e,18:25,18:27","dtypep":"(DB)"}
],
"rightp": [
{"type":"CONST","name":"?32?sh0","addr":"(KB)","loc":"e,18:28,18:29","dtypep":"(N)"}
],"attrp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
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
"lhsp": [
{"type":"PARSEREF","name":"in","addr":"(LB)","loc":"e,18:16,18:18","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
],"timingControlp": [],"strengthSpecp": []}
]},
{"type":"VAR","name":"out","addr":"(MB)","loc":"e,22:25,22:28","dtypep":"UNLINKED","origName":"out","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"WIRE","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"logic","addr":"(NB)","loc":"e,22:9,22:10","dtypep":"(NB)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
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
{"type":"RANGE","name":"","addr":"(OB)","loc":"e,22:9,22:10","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
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
{"type":"CONST","name":"?32?sh1f","addr":"(PB)","loc":"e,22:10,22:12","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(QB)","loc":"e,22:13,22:14","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"CELL","name":"test","addr":"(RB)","loc":"e,25:9,25:13","origName":"test","recursive":false,"modp":"(SB)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"pinsp": [
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
{"type":"PIN","name":"out","addr":"(TB)","loc":"e,27:15,27:18","svDotName":true,"svImplicit":false,"modVarp":"UNLINKED","modPTypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"exprp": [
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
{"type":"SELEXTRACT","name":"","addr":"(UB)","loc":"e,27:45,27:46","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"out","addr":"(VB)","loc":"e,27:42,27:45","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"leftp": [
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
{"type":"CONST","name":"?32?sh1f","addr":"(WB)","loc":"e,27:46,27:48","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(XB)","loc":"e,27:49,27:50","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"attrp": []}
]},
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
{"type":"PIN","name":"clk","addr":"(YB)","loc":"e,29:15,29:18","svDotName":true,"svImplicit":false,"modVarp":"UNLINKED","modPTypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"exprp": [
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
{"type":"PARSEREF","name":"clk","addr":"(ZB)","loc":"e,29:42,29:45","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]},
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
{"type":"PIN","name":"in","addr":"(AC)","loc":"e,30:15,30:17","svDotName":true,"svImplicit":false,"modVarp":"UNLINKED","modPTypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"exprp": [
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
{"type":"SELEXTRACT","name":"","addr":"(BC)","loc":"e,30:44,30:45","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"in","addr":"(CC)","loc":"e,30:42,30:44","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"leftp": [
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
{"type":"CONST","name":"?32?sh1f","addr":"(DC)","loc":"e,30:45,30:47","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(EC)","loc":"e,30:48,30:49","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"attrp": []}
]}
],"paramsp": [],"rangep": [],"intfRefsp": []},
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
{"type":"VAR","name":"result","addr":"(FC)","loc":"e,33:16,33:22","dtypep":"UNLINKED","origName":"result","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"WIRE","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"logic","addr":"(GC)","loc":"e,33:9,33:10","dtypep":"(GC)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
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
{"type":"RANGE","name":"","addr":"(HC)","loc":"e,33:9,33:10","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
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
{"type":"CONST","name":"?32?sh3f","addr":"(IC)","loc":"e,33:10,33:12","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(JC)","loc":"e,33:13,33:14","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"ALWAYS","name":"","addr":"(KC)","loc":"e,33:23,33:24","keyword":"cont_assign","isSuspendable":false,"needProcess":false,"sentreep": [],
"stmtsp": [
{"type":"ASSIGNW","name":"","addr":"(LC)","loc":"e,33:23,33:24","dtypep":"UNLINKED",
"rhsp": [
{"type":"REPLICATE","name":"","addr":"(MC)","loc":"e,33:25,33:26","dtypep":"(NC)",
"srcp": [
{"type":"CONCAT","name":"","addr":"(OC)","loc":"e,33:31,33:32","dtypep":"UNLINKED",
"lhsp": [
{"type":"CONST","name":"32'h0","addr":"(PC)","loc":"e,33:26,33:31","dtypep":"(QC)"}
],
"rhsp": [
{"type":"PARSEREF","name":"out","addr":"(RC)","loc":"e,33:33,33:36","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
]}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
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
"countp": [
{"type":"CONST","name":"32'h1","addr":"(SC)","loc":"e,33:25,33:26","dtypep":"(QC)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
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
"lhsp": [
{"type":"PARSEREF","name":"result","addr":"(TC)","loc":"e,33:16,33:22","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
],"timingControlp": [],"strengthSpecp": []}
]},
{"type":"ALWAYS","name":"","addr":"(UC)","loc":"e,36:4,36:10","keyword":"always","isSuspendable":false,"needProcess":false,"sentreep": [],
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"EVENTCONTROL","name":"","addr":"(VC)","loc":"e,36:11,36:12",
Internals: Rename AstSenTree pointers to sentreep. No functional change intended except JSON.
2025-08-18 01:14:34 +02:00
"sentreep": [
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
{"type":"SENTREE","name":"","addr":"(WC)","loc":"e,36:11,36:12","isMulti":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"sensesp": [
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
{"type":"SENITEM","name":"","addr":"(XC)","loc":"e,36:14,36:21","edgeType":"POS",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"sensp": [
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
{"type":"PARSEREF","name":"clk","addr":"(YC)","loc":"e,36:22,36:25","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"condp": []}
]}
],
"stmtsp": [
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
{"type":"BEGIN","name":"","addr":"(ZC)","loc":"e,36:27,36:32","implied":false,"needProcess":false,"unnamed":true,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"ASSIGNDLY","name":"","addr":"(AD)","loc":"e,40:11,40:13","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"ADD","name":"","addr":"(BD)","loc":"e,40:18,40:19","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(CD)","loc":"e,40:14,40:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh1","addr":"(DD)","loc":"e,40:20,40:21","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(ED)","loc":"e,40:7,40:10","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []},
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
{"type":"ASSIGNDLY","name":"","addr":"(FD)","loc":"e,41:11,41:13","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"REPLICATE","name":"","addr":"(GD)","loc":"e,41:14,41:15","dtypep":"(NC)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"srcp": [
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
{"type":"CONCAT","name":"","addr":"(HD)","loc":"e,41:24,41:25","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"SELEXTRACT","name":"","addr":"(ID)","loc":"e,41:18,41:19","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"crc","addr":"(JD)","loc":"e,41:15,41:18","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"leftp": [
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
{"type":"CONST","name":"?32?sh3e","addr":"(KD)","loc":"e,41:19,41:21","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(LD)","loc":"e,41:22,41:23","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"attrp": []}
],
"rhsp": [
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
{"type":"XOR","name":"","addr":"(MD)","loc":"e,41:43,41:44","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"XOR","name":"","addr":"(ND)","loc":"e,41:34,41:35","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"SELBIT","name":"","addr":"(OD)","loc":"e,41:29,41:30","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"crc","addr":"(PD)","loc":"e,41:26,41:29","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh3f","addr":"(QD)","loc":"e,41:30,41:32","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
],
"rhsp": [
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
{"type":"SELBIT","name":"","addr":"(RD)","loc":"e,41:39,41:40","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"crc","addr":"(SD)","loc":"e,41:36,41:39","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh2","addr":"(TD)","loc":"e,41:40,41:41","dtypep":"(UD)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
]}
],
"rhsp": [
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
{"type":"SELBIT","name":"","addr":"(VD)","loc":"e,41:48,41:49","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"crc","addr":"(WD)","loc":"e,41:45,41:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(XD)","loc":"e,41:49,41:50","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
]}
]}
],
"countp": [
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
{"type":"CONST","name":"32'h1","addr":"(YD)","loc":"e,41:14,41:15","dtypep":"(QC)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"crc","addr":"(ZD)","loc":"e,41:7,41:10","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []},
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
{"type":"ASSIGNDLY","name":"","addr":"(AE)","loc":"e,42:11,42:13","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"XOR","name":"","addr":"(BE)","loc":"e,42:21,42:22","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"result","addr":"(CE)","loc":"e,42:14,42:20","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"REPLICATE","name":"","addr":"(DE)","loc":"e,42:23,42:24","dtypep":"(NC)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"srcp": [
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
{"type":"CONCAT","name":"","addr":"(EE)","loc":"e,42:33,42:34","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"SELEXTRACT","name":"","addr":"(FE)","loc":"e,42:27,42:28","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"sum","addr":"(GE)","loc":"e,42:24,42:27","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"leftp": [
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
{"type":"CONST","name":"?32?sh3e","addr":"(HE)","loc":"e,42:28,42:30","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(IE)","loc":"e,42:31,42:32","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"attrp": []}
],
"rhsp": [
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
{"type":"XOR","name":"","addr":"(JE)","loc":"e,42:52,42:53","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"XOR","name":"","addr":"(KE)","loc":"e,42:43,42:44","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"SELBIT","name":"","addr":"(LE)","loc":"e,42:38,42:39","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"sum","addr":"(ME)","loc":"e,42:35,42:38","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh3f","addr":"(NE)","loc":"e,42:39,42:41","dtypep":"(S)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
],
"rhsp": [
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
{"type":"SELBIT","name":"","addr":"(OE)","loc":"e,42:48,42:49","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"sum","addr":"(PE)","loc":"e,42:45,42:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh2","addr":"(QE)","loc":"e,42:49,42:50","dtypep":"(UD)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
]}
],
"rhsp": [
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
{"type":"SELBIT","name":"","addr":"(RE)","loc":"e,42:57,42:58","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fromp": [
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
{"type":"PARSEREF","name":"sum","addr":"(SE)","loc":"e,42:54,42:57","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(TE)","loc":"e,42:58,42:59","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"thsp": [],"attrp": []}
]}
]}
],
"countp": [
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
{"type":"CONST","name":"32'h1","addr":"(UE)","loc":"e,42:23,42:24","dtypep":"(QC)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"sum","addr":"(VE)","loc":"e,42:7,42:10","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []},
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
{"type":"IF","name":"","addr":"(WE)","loc":"e,43:7,43:9",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"EQ","name":"","addr":"(XE)","loc":"e,43:15,43:17","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(ZE)","loc":"e,43:11,43:14","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(AF)","loc":"e,43:18,43:19","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(BF)","loc":"e,43:21,43:26","implied":false,"needProcess":false,"unnamed":true,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"ASSIGNDLY","name":"","addr":"(CF)","loc":"e,45:14,45:16","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"CONST","name":"64'h5aef0c8dd70a4497","addr":"(DF)","loc":"e,45:17,45:38","dtypep":"(EF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"crc","addr":"(FF)","loc":"e,45:10,45:13","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []},
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
{"type":"ASSIGNDLY","name":"","addr":"(GF)","loc":"e,46:14,46:16","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"CONST","name":"'0","addr":"(HF)","loc":"e,46:17,46:19","dtypep":"(YE)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"sum","addr":"(IF)","loc":"e,46:10,46:13","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []}
]}
],
"elsesp": [
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
{"type":"IF","name":"","addr":"(JF)","loc":"e,48:12,48:14",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"LT","name":"","addr":"(KF)","loc":"e,48:20,48:21","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(LF)","loc":"e,48:16,48:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sha","addr":"(MF)","loc":"e,48:22,48:24","dtypep":"(NF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(OF)","loc":"e,48:26,48:31","implied":false,"needProcess":false,"unnamed":true,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"ASSIGNDLY","name":"","addr":"(PF)","loc":"e,49:14,49:16","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"CONST","name":"'0","addr":"(QF)","loc":"e,49:17,49:19","dtypep":"(YE)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"sum","addr":"(RF)","loc":"e,49:10,49:13","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"timingControlp": []}
]}
],
"elsesp": [
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
{"type":"IF","name":"","addr":"(SF)","loc":"e,51:12,51:14",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"LT","name":"","addr":"(TF)","loc":"e,51:20,51:21","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(UF)","loc":"e,51:16,51:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh5a","addr":"(VF)","loc":"e,51:22,51:24","dtypep":"(WF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(XF)","loc":"e,51:26,51:31","implied":false,"needProcess":false,"unnamed":true,"stmtsp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"elsesp": [
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
{"type":"IF","name":"","addr":"(YF)","loc":"e,53:12,53:14",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"EQ","name":"","addr":"(ZF)","loc":"e,53:20,53:22","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"cyc","addr":"(AG)","loc":"e,53:16,53:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh63","addr":"(BG)","loc":"e,53:23,53:25","dtypep":"(WF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(CG)","loc":"e,53:27,53:32","implied":false,"needProcess":false,"unnamed":true,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"DISPLAY","name":"","addr":"(DG)","loc":"e,54:10,54:16",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(EG)","loc":"e,54:10,54:16","dtypep":"(FG)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"exprsp": [
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
{"type":"CONST","name":"232'h5b2530745d206379633d3d253064206372633d25782073756d3d25780a","addr":"(GG)","loc":"e,54:17,54:49","dtypep":"(HG)"},
{"type":"TIME","name":"","addr":"(IG)","loc":"e,54:51,54:56","dtypep":"(JG)","timeunit":"NONE"},
{"type":"PARSEREF","name":"cyc","addr":"(KG)","loc":"e,54:58,54:61","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
{"type":"PARSEREF","name":"crc","addr":"(LG)","loc":"e,54:63,54:66","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
{"type":"PARSEREF","name":"sum","addr":"(MG)","loc":"e,54:68,54:71","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"scopeNamep": []}
],"filep": []},
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
{"type":"IF","name":"","addr":"(NG)","loc":"e,55:10,55:12",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"NEQCASE","name":"","addr":"(OG)","loc":"e,55:18,55:21","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"crc","addr":"(PG)","loc":"e,55:14,55:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"64'hc77bb9b3784ea091","addr":"(QG)","loc":"e,55:22,55:42","dtypep":"(EF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"STOP","name":"","addr":"(RG)","loc":"e,55:44,55:49","isFatal":false}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"elsesp": []},
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
{"type":"IF","name":"","addr":"(SG)","loc":"e,58:10,58:12",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"condp": [
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
{"type":"NEQCASE","name":"","addr":"(TG)","loc":"e,58:18,58:21","dtypep":"(YE)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"lhsp": [
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
{"type":"PARSEREF","name":"sum","addr":"(UG)","loc":"e,58:14,58:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rhsp": [
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
{"type":"CONST","name":"64'h4afe43fb79d7b71e","addr":"(VG)","loc":"e,58:22,58:42","dtypep":"(EF)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],
"thensp": [
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
{"type":"STOP","name":"","addr":"(WG)","loc":"e,58:44,58:49","isFatal":false}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"elsesp": []},
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
{"type":"DISPLAY","name":"","addr":"(XG)","loc":"e,59:10,59:16",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(YG)","loc":"e,59:10,59:16","dtypep":"(FG)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"exprsp": [
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
{"type":"CONST","name":"168'h2a2d2a20416c6c2046696e6973686564202a2d2a0a","addr":"(ZG)","loc":"e,59:17,59:41","dtypep":"(AH)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"scopeNamep": []}
],"filep": []},
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
{"type":"FINISH","name":"","addr":"(BH)","loc":"e,60:10,60:17"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
],"elsesp": []}
]}
]}
]}
]}
]}
]}
Internals: Remove unused AstNodeModule 'activesp' child (#6138)
2025-06-29 15:56:44 +02:00
]},
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
{"type":"MODULE","name":"Test","addr":"(SB)","loc":"e,66:8,66:12","isChecker":false,"isProgram":false,"hasGenericIface":false,"origName":"Test","level":3,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"1ps","inlinesp": [],
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"PORT","name":"out","addr":"(CH)","loc":"e,68:4,68:7","exprp": []},
{"type":"PORT","name":"clk","addr":"(DH)","loc":"e,70:4,70:7","exprp": []},
{"type":"PORT","name":"in","addr":"(EH)","loc":"e,70:9,70:11","exprp": []},
{"type":"VAR","name":"clk","addr":"(FH)","loc":"e,78:10,78:13","dtypep":"UNLINKED","origName":"clk","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"LOGIC_IMPLICIT","addr":"(GH)","loc":"e,78:10,78:13","dtypep":"(GH)","keyword":"LOGIC_IMPLICIT","generic":false,"rangep": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"in","addr":"(HH)","loc":"e,79:17,79:19","dtypep":"UNLINKED","origName":"in","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"logic","addr":"(IH)","loc":"e,79:10,79:11","dtypep":"(IH)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
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
{"type":"RANGE","name":"","addr":"(JH)","loc":"e,79:10,79:11","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
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
{"type":"CONST","name":"?32?sh1f","addr":"(KH)","loc":"e,79:11,79:13","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(LH)","loc":"e,79:14,79:15","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"out","addr":"(MH)","loc":"e,80:22,80:25","dtypep":"UNLINKED","origName":"out","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"OUTPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"logic","addr":"(NH)","loc":"e,80:11,80:14","dtypep":"(NH)","keyword":"logic","generic":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rangep": [
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
{"type":"RANGE","name":"","addr":"(OH)","loc":"e,80:15,80:16","ascending":false,"fromBracket":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"leftp": [
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
{"type":"CONST","name":"?32?sh1f","addr":"(PH)","loc":"e,80:16,80:18","dtypep":"(DB)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"rightp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(QH)","loc":"e,80:19,80:20","dtypep":"(N)"}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"ALWAYS","name":"","addr":"(RH)","loc":"e,82:4,82:10","keyword":"always","isSuspendable":false,"needProcess":false,"sentreep": [],
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"EVENTCONTROL","name":"","addr":"(SH)","loc":"e,82:11,82:12",
Internals: Rename AstSenTree pointers to sentreep. No functional change intended except JSON.
2025-08-18 01:14:34 +02:00
"sentreep": [
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
{"type":"SENTREE","name":"","addr":"(TH)","loc":"e,82:11,82:12","isMulti":false,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"sensesp": [
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
{"type":"SENITEM","name":"","addr":"(UH)","loc":"e,82:13,82:20","edgeType":"POS",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"sensp": [
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
{"type":"PARSEREF","name":"clk","addr":"(VH)","loc":"e,82:21,82:24","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"condp": []}
]}
],
"stmtsp": [
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
{"type":"BEGIN","name":"","addr":"(WH)","loc":"e,82:26,82:31","implied":false,"needProcess":false,"unnamed":true,
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"ASSIGNDLY","name":"","addr":"(XH)","loc":"e,83:11,83:13","dtypep":"UNLINKED",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"rhsp": [
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
{"type":"PARSEREF","name":"in","addr":"(YH)","loc":"e,83:14,83:16","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"out","addr":"(ZH)","loc":"e,83:7,83:10","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
],"timingControlp": []},
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
{"type":"ASSERTCTL","name":"","addr":"(AI)","loc":"e,86:7,86:17",
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
"controlTypep": [
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
{"type":"CONST","name":"32'h4","addr":"(BI)","loc":"e,86:7,86:17","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"assertTypesp": [
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
{"type":"CONST","name":"32'hf","addr":"(CI)","loc":"e,86:7,86:17","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"directiveTypesp": [
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
{"type":"CONST","name":"32'h7","addr":"(DI)","loc":"e,86:7,86:17","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
]},
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
{"type":"ASSERTCTL","name":"","addr":"(EI)","loc":"e,87:7,87:18",
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
"controlTypep": [
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
{"type":"CONST","name":"32'h5","addr":"(FI)","loc":"e,87:7,87:18","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"assertTypesp": [
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
{"type":"CONST","name":"32'hf","addr":"(GI)","loc":"e,87:7,87:18","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"directiveTypesp": [
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
{"type":"CONST","name":"32'h7","addr":"(HI)","loc":"e,87:7,87:18","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
]},
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
{"type":"ASSERT","name":"","addr":"(II)","loc":"e,88:7,88:13","type":"[SIMPLE_IMMEDIATE]",
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(JI)","loc":"e,88:14,88:15","dtypep":"(N)"}
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
],"sentreep": [],"failsp": [],"passsp": []},
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
{"type":"ASSERTCTL","name":"","addr":"(KI)","loc":"e,89:7,89:16",
Add parameterless assert control system tasks (#5010) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org> Co-authored-by: Arkadiusz Kozdra <akozdra@antmicro.com>
2024-05-08 14:31:34 +02:00
"controlTypep": [
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
{"type":"CONST","name":"32'h3","addr":"(LI)","loc":"e,89:7,89:16","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"assertTypesp": [
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
{"type":"CONST","name":"32'hf","addr":"(MI)","loc":"e,89:7,89:16","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
],
"directiveTypesp": [
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
{"type":"CONST","name":"32'h7","addr":"(NI)","loc":"e,89:7,89:16","dtypep":"(QC)"}
Add parsing of `$assert*`, `$coverage*` and `$q_*` as still unsupported.
2025-09-06 16:31:08 +02:00
]},
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
{"type":"ASSERTCTL","name":"","addr":"(OI)","loc":"e,90:7,90:21",
Support `$assertcontrol` assertion_type (#5236) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Signed-off-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org>
2024-07-10 11:06:13 +02:00
"controlTypep": [
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
{"type":"CONST","name":"?32?sh3","addr":"(PI)","loc":"e,90:22,90:23","dtypep":"(UD)"}
Support `$assertcontrol` assertion_type (#5236) Signed-off-by: Bartłomiej Chmiel <bchmiel@antmicro.com> Signed-off-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Ryszard Rozak <rrozak@antmicro.com> Co-authored-by: Wilson Snyder <wsnyder@wsnyder.org>
2024-07-10 11:06:13 +02:00
],
"assertTypesp": [
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
{"type":"CONST","name":"?32?sh8","addr":"(QI)","loc":"e,90:25,90:26","dtypep":"(NF)"}
Support disable dotted references (#6154)
2025-07-09 22:59:26 +02:00
],"directiveTypesp": []},
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
{"type":"BEGIN","name":"blk","addr":"(RI)","loc":"e,91:15,91:18","implied":false,"needProcess":false,"unnamed":false,
Support disable dotted references (#6154)
2025-07-09 22:59:26 +02:00
"stmtsp": [
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
{"type":"DISABLE","name":"","addr":"(SI)","loc":"e,92:10,92:17",
Support disable dotted references (#6154)
2025-07-09 22:59:26 +02:00
"targetRefp": [
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
{"type":"PARSEREF","name":"blk","addr":"(TI)","loc":"e,92:18,92:21","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disable dotted references (#6154)
2025-07-09 22:59:26 +02:00
]}
]}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]},
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
{"type":"INITIAL","name":"","addr":"(UI)","loc":"e,95:4,95:11","isSuspendable":false,"needProcess":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"","addr":"(VI)","loc":"e,95:12,95:17","implied":false,"needProcess":false,"unnamed":true,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_simple_immediate_else","addr":"(WI)","loc":"e,96:7,96:35","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(XI)","loc":"e,96:37,96:43","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(YI)","loc":"e,96:44,96:45","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(ZI)","loc":"e,96:52,96:60",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(AJ)","loc":"e,96:52,96:60","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(BJ)","loc":"e,96:61,96:67","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]},
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
{"type":"BEGIN","name":"assert_simple_immediate_stmt","addr":"(CJ)","loc":"e,97:7,97:35","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(DJ)","loc":"e,97:37,97:43","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(EJ)","loc":"e,97:44,97:45","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(FJ)","loc":"e,97:47,97:55",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(GJ)","loc":"e,97:47,97:55","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(HJ)","loc":"e,97:56,97:62","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assert_simple_immediate_stmt_else","addr":"(IJ)","loc":"e,98:7,98:40","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(JJ)","loc":"e,98:42,98:48","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(KJ)","loc":"e,98:49,98:50","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(LJ)","loc":"e,98:75,98:83",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(MJ)","loc":"e,98:75,98:83","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(NJ)","loc":"e,98:84,98:90","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(OJ)","loc":"e,98:52,98:60",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(PJ)","loc":"e,98:52,98:60","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(QJ)","loc":"e,98:61,98:67","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assume_simple_immediate","addr":"(RJ)","loc":"e,100:7,100:30","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(SJ)","loc":"e,100:32,100:38","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(TJ)","loc":"e,100:39,100:40","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],"passsp": []}
]},
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
{"type":"BEGIN","name":"assume_simple_immediate_else","addr":"(UJ)","loc":"e,101:7,101:35","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(VJ)","loc":"e,101:37,101:43","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(WJ)","loc":"e,101:44,101:45","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(XJ)","loc":"e,101:52,101:60",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(YJ)","loc":"e,101:52,101:60","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(ZJ)","loc":"e,101:61,101:67","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]},
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
{"type":"BEGIN","name":"assume_simple_immediate_stmt","addr":"(AK)","loc":"e,102:7,102:35","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(BK)","loc":"e,102:37,102:43","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(CK)","loc":"e,102:44,102:45","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(DK)","loc":"e,102:47,102:55",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(EK)","loc":"e,102:47,102:55","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(FK)","loc":"e,102:56,102:62","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assume_simple_immediate_stmt_else","addr":"(GK)","loc":"e,103:7,103:40","implied":false,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(HK)","loc":"e,103:42,103:48","type":"[SIMPLE_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(IK)","loc":"e,103:49,103:50","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(JK)","loc":"e,103:75,103:83",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(KK)","loc":"e,103:75,103:83","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(LK)","loc":"e,103:84,103:90","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(MK)","loc":"e,103:52,103:60",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(NK)","loc":"e,103:52,103:60","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(OK)","loc":"e,103:61,103:67","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(PK)","loc":"e,106:4,106:38","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_observed_deferred_immediate","addr":"(QK)","loc":"e,106:4,106:38","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(RK)","loc":"e,106:40,106:46","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(SK)","loc":"e,106:51,106:52","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(TK)","loc":"e,107:4,107:43","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_observed_deferred_immediate_else","addr":"(UK)","loc":"e,107:4,107:43","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(VK)","loc":"e,107:45,107:51","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(WK)","loc":"e,107:56,107:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(XK)","loc":"e,107:64,107:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(YK)","loc":"e,107:64,107:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(ZK)","loc":"e,107:73,107:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(AL)","loc":"e,108:4,108:43","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_observed_deferred_immediate_stmt","addr":"(BL)","loc":"e,108:4,108:43","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(CL)","loc":"e,108:45,108:51","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(DL)","loc":"e,108:56,108:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(EL)","loc":"e,108:59,108:67",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(FL)","loc":"e,108:59,108:67","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(GL)","loc":"e,108:68,108:74","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(HL)","loc":"e,109:4,109:48","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_observed_deferred_immediate_stmt_else","addr":"(IL)","loc":"e,109:4,109:48","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(JL)","loc":"e,109:50,109:56","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(KL)","loc":"e,109:61,109:62","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(LL)","loc":"e,109:87,109:95",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(ML)","loc":"e,109:87,109:95","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(NL)","loc":"e,109:96,109:102","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(OL)","loc":"e,109:64,109:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(PL)","loc":"e,109:64,109:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(QL)","loc":"e,109:73,109:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(RL)","loc":"e,111:4,111:38","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_observed_deferred_immediate","addr":"(SL)","loc":"e,111:4,111:38","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(TL)","loc":"e,111:40,111:46","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(UL)","loc":"e,111:51,111:52","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(VL)","loc":"e,112:4,112:43","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_observed_deferred_immediate_else","addr":"(WL)","loc":"e,112:4,112:43","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(XL)","loc":"e,112:45,112:51","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(YL)","loc":"e,112:56,112:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(ZL)","loc":"e,112:64,112:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(AM)","loc":"e,112:64,112:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(BM)","loc":"e,112:73,112:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(CM)","loc":"e,113:4,113:43","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_observed_deferred_immediate_stmt","addr":"(DM)","loc":"e,113:4,113:43","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(EM)","loc":"e,113:45,113:51","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(FM)","loc":"e,113:56,113:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(GM)","loc":"e,113:59,113:67",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(HM)","loc":"e,113:59,113:67","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(IM)","loc":"e,113:68,113:74","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(JM)","loc":"e,114:4,114:48","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_observed_deferred_immediate_stmt_else","addr":"(KM)","loc":"e,114:4,114:48","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(LM)","loc":"e,114:50,114:56","type":"[OBSERVED_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(MM)","loc":"e,114:61,114:62","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(NM)","loc":"e,114:87,114:95",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(OM)","loc":"e,114:87,114:95","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(PM)","loc":"e,114:96,114:102","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(QM)","loc":"e,114:64,114:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(RM)","loc":"e,114:64,114:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(SM)","loc":"e,114:73,114:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(TM)","loc":"e,116:4,116:35","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_final_deferred_immediate","addr":"(UM)","loc":"e,116:4,116:35","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(VM)","loc":"e,116:37,116:43","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(WM)","loc":"e,116:51,116:52","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(XM)","loc":"e,117:4,117:40","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_final_deferred_immediate_else","addr":"(YM)","loc":"e,117:4,117:40","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(ZM)","loc":"e,117:42,117:48","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(AN)","loc":"e,117:56,117:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(BN)","loc":"e,117:64,117:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(CN)","loc":"e,117:64,117:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(DN)","loc":"e,117:73,117:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(EN)","loc":"e,118:4,118:40","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_final_deferred_immediate_stmt","addr":"(FN)","loc":"e,118:4,118:40","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(GN)","loc":"e,118:42,118:48","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(HN)","loc":"e,118:56,118:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(IN)","loc":"e,118:59,118:67",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(JN)","loc":"e,118:59,118:67","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(KN)","loc":"e,118:68,118:74","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(LN)","loc":"e,119:4,119:45","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assert_final_deferred_immediate_stmt_else","addr":"(MN)","loc":"e,119:4,119:45","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(NN)","loc":"e,119:47,119:53","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(ON)","loc":"e,119:61,119:62","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(PN)","loc":"e,119:87,119:95",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(QN)","loc":"e,119:87,119:95","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(RN)","loc":"e,119:96,119:102","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(SN)","loc":"e,119:64,119:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(TN)","loc":"e,119:64,119:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(UN)","loc":"e,119:73,119:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(VN)","loc":"e,121:4,121:35","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_final_deferred_immediate","addr":"(WN)","loc":"e,121:4,121:35","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(XN)","loc":"e,121:37,121:43","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(YN)","loc":"e,121:51,121:52","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(ZN)","loc":"e,122:4,122:40","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_final_deferred_immediate_else","addr":"(AO)","loc":"e,122:4,122:40","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(BO)","loc":"e,122:42,122:48","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(CO)","loc":"e,122:56,122:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(DO)","loc":"e,122:64,122:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(EO)","loc":"e,122:64,122:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(FO)","loc":"e,122:73,122:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(GO)","loc":"e,123:4,123:40","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_final_deferred_immediate_stmt","addr":"(HO)","loc":"e,123:4,123:40","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(IO)","loc":"e,123:42,123:48","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(JO)","loc":"e,123:56,123:57","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(KO)","loc":"e,123:59,123:67",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(LO)","loc":"e,123:59,123:67","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(MO)","loc":"e,123:68,123:74","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"ALWAYS","name":"","addr":"(NO)","loc":"e,124:4,124:45","keyword":"always_comb","isSuspendable":false,"needProcess":false,"sentreep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"BEGIN","name":"assume_final_deferred_immediate_stmt_else","addr":"(OO)","loc":"e,124:4,124:45","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(PO)","loc":"e,124:47,124:53","type":"[FINAL_DEFERRED_IMMEDIATE]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(QO)","loc":"e,124:61,124:62","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(RO)","loc":"e,124:87,124:95",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(SO)","loc":"e,124:87,124:95","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(TO)","loc":"e,124:96,124:102","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(UO)","loc":"e,124:64,124:72",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(VO)","loc":"e,124:64,124:72","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(WO)","loc":"e,124:73,124:79","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]}
]},
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
{"type":"PROPERTY","name":"prop","addr":"(XO)","loc":"e,126:13,126:17","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"prop","fvarp": [],"classOrPackagep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"PROPSPEC","name":"","addr":"(YO)","loc":"e,127:7,127:8","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"sensesp": [
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
{"type":"SENITEM","name":"","addr":"(ZO)","loc":"e,127:9,127:16","edgeType":"POS",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"sensp": [
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
{"type":"PARSEREF","name":"clk","addr":"(AP)","loc":"e,127:17,127:20","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"condp": []}
],"disablep": [],
"propp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(BP)","loc":"e,127:22,127:23","dtypep":"(N)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
],"scopeNamep": []},
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
{"type":"BEGIN","name":"assert_concurrent","addr":"(CP)","loc":"e,130:4,130:21","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(DP)","loc":"e,130:23,130:29","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(EP)","loc":"e,130:23,130:29","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(FP)","loc":"e,130:40,130:44","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(GP)","loc":"e,130:40,130:44","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],"failsp": [],"passsp": []}
]},
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
{"type":"BEGIN","name":"assert_concurrent_else","addr":"(HP)","loc":"e,131:4,131:26","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(IP)","loc":"e,131:28,131:34","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(JP)","loc":"e,131:28,131:34","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(KP)","loc":"e,131:44,131:48","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(LP)","loc":"e,131:44,131:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(MP)","loc":"e,131:55,131:63",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(NP)","loc":"e,131:55,131:63","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(OP)","loc":"e,131:64,131:70","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]},
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
{"type":"BEGIN","name":"assert_concurrent_stmt","addr":"(PP)","loc":"e,132:4,132:26","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(QP)","loc":"e,132:28,132:34","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(RP)","loc":"e,132:28,132:34","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(SP)","loc":"e,132:44,132:48","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(TP)","loc":"e,132:44,132:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(UP)","loc":"e,132:50,132:58",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(VP)","loc":"e,132:50,132:58","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(WP)","loc":"e,132:59,132:65","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assert_concurrent_stmt_else","addr":"(XP)","loc":"e,133:4,133:31","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(YP)","loc":"e,133:33,133:39","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(ZP)","loc":"e,133:33,133:39","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(AQ)","loc":"e,133:49,133:53","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(BQ)","loc":"e,133:49,133:53","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(CQ)","loc":"e,133:78,133:86",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(DQ)","loc":"e,133:78,133:86","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(EQ)","loc":"e,133:87,133:93","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(FQ)","loc":"e,133:55,133:63",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(GQ)","loc":"e,133:55,133:63","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(HQ)","loc":"e,133:64,133:70","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assume_concurrent","addr":"(IQ)","loc":"e,135:4,135:21","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(JQ)","loc":"e,135:23,135:29","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(KQ)","loc":"e,135:23,135:29","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(LQ)","loc":"e,135:39,135:43","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(MQ)","loc":"e,135:39,135:43","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],"failsp": [],"passsp": []}
]},
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
{"type":"BEGIN","name":"assume_concurrent_else","addr":"(NQ)","loc":"e,136:4,136:26","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(OQ)","loc":"e,136:28,136:34","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(PQ)","loc":"e,136:28,136:34","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(QQ)","loc":"e,136:44,136:48","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(RQ)","loc":"e,136:44,136:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(SQ)","loc":"e,136:55,136:63",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(TQ)","loc":"e,136:55,136:63","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(UQ)","loc":"e,136:64,136:70","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],"passsp": []}
]},
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
{"type":"BEGIN","name":"assume_concurrent_stmt","addr":"(VQ)","loc":"e,137:4,137:26","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(WQ)","loc":"e,137:28,137:34","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(XQ)","loc":"e,137:28,137:34","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(YQ)","loc":"e,137:44,137:48","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(ZQ)","loc":"e,137:44,137:48","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],"failsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(AR)","loc":"e,137:50,137:58",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(BR)","loc":"e,137:50,137:58","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(CR)","loc":"e,137:59,137:65","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"assume_concurrent_stmt_else","addr":"(DR)","loc":"e,138:4,138:31","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"ASSERT","name":"","addr":"(ER)","loc":"e,138:33,138:39","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"SAMPLED","name":"","addr":"(FR)","loc":"e,138:33,138:39","dtypep":"UNLINKED",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprp": [
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
{"type":"PROPSPEC","name":"","addr":"(GR)","loc":"e,138:49,138:53","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(HR)","loc":"e,138:49,138:53","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
]}
],"sentreep": [],
"failsp": [
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
{"type":"DISPLAY","name":"","addr":"(IR)","loc":"e,138:78,138:86",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(JR)","loc":"e,138:78,138:86","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h6661696c","addr":"(KR)","loc":"e,138:87,138:93","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(LR)","loc":"e,138:55,138:63",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(MR)","loc":"e,138:55,138:63","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(NR)","loc":"e,138:64,138:70","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"BEGIN","name":"cover_concurrent","addr":"(OR)","loc":"e,140:4,140:20","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"COVER","name":"","addr":"(PR)","loc":"e,140:22,140:27","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PROPSPEC","name":"","addr":"(QR)","loc":"e,140:37,140:41","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(RR)","loc":"e,140:37,140:41","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
],"sentreep": [],"coverincsp": [],"passsp": []}
]},
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
{"type":"BEGIN","name":"cover_concurrent_stmt","addr":"(SR)","loc":"e,141:4,141:25","implied":true,"needProcess":false,"unnamed":false,
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
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
{"type":"COVER","name":"","addr":"(TR)","loc":"e,141:27,141:32","type":"[CONCURRENT]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PROPSPEC","name":"","addr":"(UR)","loc":"e,141:42,141:46","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(VR)","loc":"e,141:42,141:46","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
],"sentreep": [],"coverincsp": [],
"passsp": [
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
{"type":"DISPLAY","name":"","addr":"(WR)","loc":"e,141:48,141:56",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(XR)","loc":"e,141:48,141:56","dtypep":"(FG)",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"exprsp": [
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
{"type":"CONST","name":"32'h70617373","addr":"(YR)","loc":"e,141:57,141:63","dtypep":"(QC)"}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
],"scopeNamep": []}
],"filep": []}
]}
]},
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
{"type":"RESTRICT","name":"","addr":"(ZR)","loc":"e,143:4,143:12","type":"[INTERNAL]",
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PROPSPEC","name":"","addr":"(AS)","loc":"e,143:23,143:27","dtypep":"UNLINKED","sensesp": [],"disablep": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"propp": [
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
{"type":"PARSEREF","name":"prop","addr":"(BS)","loc":"e,143:23,143:27","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
]}
],"sentreep": [],"passsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
{"type":"PACKAGE","name":"$unit","addr":"(E)","loc":"a,0:0,0:0","origName":"__024unit","level":3,"modPublic":false,"inLibrary":true,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"1ps","inlinesp": [],
"stmtsp": [
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
{"type":"PACKAGEIMPORT","name":"*","addr":"(CS)","loc":"d,31:9,31:12","packagep":"(F)","resolvedClassp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
{"type":"PACKAGE","name":"std","addr":"(F)","loc":"d,31:9,31:12","origName":"std","level":4,"modPublic":false,"inLibrary":true,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"1ps","inlinesp": [],
"stmtsp": [
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
{"type":"CLASS","name":"mailbox","addr":"(DS)","loc":"d,32:3,32:8","isExtended":false,"isInterfaceClass":false,"isVirtual":false,"origName":"mailbox","level":5,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"NONE","classOrPackagep":"UNLINKED","inlinesp": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"T","addr":"(ES)","loc":"d,33:12,33:13","dtypep":"UNLINKED","origName":"T","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"GPARAM","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":true,"isParam":true,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"PARSETYPEDTYPE","name":"","addr":"(FS)","loc":"d,33:7,33:11","dtypep":"UNLINKED","generic":false}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"TYPEDEFFWD","name":"T","addr":"(GS)","loc":"d,33:12,33:13","fwdType":"none"},
{"type":"VAR","name":"m_bound","addr":"(HS)","loc":"d,35:19,35:26","dtypep":"UNLINKED","origName":"m_bound","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(IS)","loc":"d,35:15,35:18","dtypep":"(IS)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"VAR","name":"m_queue","addr":"(JS)","loc":"d,36:17,36:24","dtypep":"UNLINKED","origName":"m_queue","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BRACKETARRAYDTYPE","name":"","addr":"(KS)","loc":"d,36:24,36:25","dtypep":"UNLINKED","generic":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(LS)","loc":"d,36:15,36:16","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"elementsp": [
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
{"type":"UNBOUNDED","name":"","addr":"(MS)","loc":"d,36:25,36:26","dtypep":"(NS)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"FUNC","name":"new","addr":"(OS)","loc":"d,38:14,38:17","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"new","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"bound","addr":"(PS)","loc":"d,38:22,38:27","dtypep":"UNLINKED","origName":"bound","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(QS)","loc":"d,38:18,38:21","dtypep":"(QS)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"CONST","name":"?32?sh0","addr":"(RS)","loc":"d,38:30,38:31","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []},
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
{"type":"ASSIGN","name":"","addr":"(SS)","loc":"d,39:15,39:16","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"PARSEREF","name":"bound","addr":"(TS)","loc":"d,39:17,39:22","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"m_bound","addr":"(US)","loc":"d,39:7,39:14","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"num","addr":"(VS)","loc":"d,42:18,42:21","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"num",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(WS)","loc":"d,42:14,42:17","dtypep":"(WS)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"RETURN","name":"","addr":"(XS)","loc":"d,43:7,43:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"DOT","name":"","addr":"(YS)","loc":"d,43:21,43:22","dtypep":"UNLINKED","colon":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_queue","addr":"(ZS)","loc":"d,43:14,43:21","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"FUNCREF","name":"size","addr":"(AT)","loc":"d,43:22,43:26","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"put","addr":"(BT)","loc":"d,46:10,46:13","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"put","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(CT)","loc":"d,46:16,46:23","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(DT)","loc":"d,46:14,46:15","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"try_put","addr":"(ET)","loc":"d,54:18,54:25","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"try_put",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(FT)","loc":"d,54:14,54:17","dtypep":"(FT)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(GT)","loc":"d,54:28,54:35","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(HT)","loc":"d,54:26,54:27","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"IF","name":"","addr":"(IT)","loc":"d,55:7,55:9",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"condp": [
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
{"type":"LOGOR","name":"","addr":"(JT)","loc":"d,55:24,55:26","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"EQ","name":"","addr":"(KT)","loc":"d,55:19,55:21","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_bound","addr":"(LT)","loc":"d,55:11,55:18","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(MT)","loc":"d,55:22,55:23","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"rhsp": [
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
{"type":"LT","name":"","addr":"(NT)","loc":"d,55:33,55:34","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"FUNCREF","name":"num","addr":"(OT)","loc":"d,55:27,55:30","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"PARSEREF","name":"m_bound","addr":"(PT)","loc":"d,55:35,55:42","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(QT)","loc":"d,55:44,55:49","implied":false,"needProcess":false,"unnamed":true,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"STMTEXPR","name":"","addr":"(RT)","loc":"d,56:16,56:17",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"DOT","name":"","addr":"(ST)","loc":"d,56:16,56:17","dtypep":"UNLINKED","colon":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_queue","addr":"(TT)","loc":"d,56:9,56:16","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"TASKREF","name":"push_back","addr":"(UT)","loc":"d,56:17,56:26","dtypep":"(VT)","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"pinsp": [
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
{"type":"ARG","name":"","addr":"(WT)","loc":"d,56:27,56:34",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"PARSEREF","name":"message","addr":"(XT)","loc":"d,56:27,56:34","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
]},
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
{"type":"RETURN","name":"","addr":"(YT)","loc":"d,57:9,57:15",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh1","addr":"(ZT)","loc":"d,57:16,57:17","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],"elsesp": []},
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
{"type":"RETURN","name":"","addr":"(AU)","loc":"d,59:7,59:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(BU)","loc":"d,59:14,59:15","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"get","addr":"(CU)","loc":"d,62:10,62:13","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"get","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(DU)","loc":"d,62:20,62:27","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"REF","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(EU)","loc":"d,62:18,62:19","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"try_get","addr":"(FU)","loc":"d,71:18,71:25","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"try_get",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(GU)","loc":"d,71:14,71:17","dtypep":"(GU)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(HU)","loc":"d,71:32,71:39","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"REF","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(IU)","loc":"d,71:30,71:31","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"IF","name":"","addr":"(JU)","loc":"d,72:7,72:9",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"condp": [
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
{"type":"GT","name":"","addr":"(KU)","loc":"d,72:17,72:18","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"FUNCREF","name":"num","addr":"(LU)","loc":"d,72:11,72:14","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(MU)","loc":"d,72:19,72:20","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(NU)","loc":"d,72:22,72:27","implied":false,"needProcess":false,"unnamed":true,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"ASSIGN","name":"","addr":"(OU)","loc":"d,73:17,73:18","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"DOT","name":"","addr":"(PU)","loc":"d,73:26,73:27","dtypep":"UNLINKED","colon":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_queue","addr":"(QU)","loc":"d,73:19,73:26","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"FUNCREF","name":"pop_front","addr":"(RU)","loc":"d,73:27,73:36","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"message","addr":"(SU)","loc":"d,73:9,73:16","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []},
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
{"type":"RETURN","name":"","addr":"(TU)","loc":"d,74:9,74:15",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh1","addr":"(UU)","loc":"d,74:16,74:17","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],"elsesp": []},
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
{"type":"RETURN","name":"","addr":"(VU)","loc":"d,76:7,76:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(WU)","loc":"d,76:14,76:15","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"peek","addr":"(XU)","loc":"d,79:10,79:14","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"peek","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(YU)","loc":"d,79:21,79:28","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"REF","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(ZU)","loc":"d,79:19,79:20","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"try_peek","addr":"(AV)","loc":"d,88:18,88:26","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"try_peek",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(BV)","loc":"d,88:14,88:17","dtypep":"(BV)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"message","addr":"(CV)","loc":"d,88:33,88:40","dtypep":"UNLINKED","origName":"message","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"REF","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"T","addr":"(DV)","loc":"d,88:31,88:32","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"IF","name":"","addr":"(EV)","loc":"d,89:7,89:9",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"condp": [
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
{"type":"GT","name":"","addr":"(FV)","loc":"d,89:17,89:18","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"FUNCREF","name":"num","addr":"(GV)","loc":"d,89:11,89:14","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(HV)","loc":"d,89:19,89:20","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(IV)","loc":"d,89:22,89:27","implied":false,"needProcess":false,"unnamed":true,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"ASSIGN","name":"","addr":"(JV)","loc":"d,90:17,90:18","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"SELBIT","name":"","addr":"(KV)","loc":"d,90:26,90:27","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fromp": [
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
{"type":"PARSEREF","name":"m_queue","addr":"(LV)","loc":"d,90:19,90:26","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"bitp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(MV)","loc":"d,90:27,90:28","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"thsp": [],"attrp": []}
],
"lhsp": [
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
{"type":"PARSEREF","name":"message","addr":"(NV)","loc":"d,90:9,90:16","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []},
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
{"type":"RETURN","name":"","addr":"(OV)","loc":"d,91:9,91:15",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh1","addr":"(PV)","loc":"d,91:16,91:17","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],"elsesp": []},
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
{"type":"RETURN","name":"","addr":"(QV)","loc":"d,93:7,93:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(RV)","loc":"d,93:14,93:15","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
],"extendsp": []},
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
{"type":"CLASS","name":"semaphore","addr":"(SV)","loc":"d,97:3,97:8","isExtended":false,"isInterfaceClass":false,"isVirtual":false,"origName":"semaphore","level":5,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"NONE","classOrPackagep":"UNLINKED","inlinesp": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"m_keyCount","addr":"(TV)","loc":"d,98:19,98:29","dtypep":"UNLINKED","origName":"m_keyCount","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(UV)","loc":"d,98:15,98:18","dtypep":"(UV)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"FUNC","name":"new","addr":"(VV)","loc":"d,100:14,100:17","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"new","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"keyCount","addr":"(WV)","loc":"d,100:22,100:30","dtypep":"UNLINKED","origName":"keyCount","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(XV)","loc":"d,100:18,100:21","dtypep":"(XV)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"CONST","name":"?32?sh0","addr":"(YV)","loc":"d,100:33,100:34","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []},
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
{"type":"ASSIGN","name":"","addr":"(ZV)","loc":"d,101:18,101:19","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"PARSEREF","name":"keyCount","addr":"(AW)","loc":"d,101:20,101:28","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(BW)","loc":"d,101:7,101:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []}
],"scopeNamep": []},
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
{"type":"TASK","name":"put","addr":"(CW)","loc":"d,104:19,104:22","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"put","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"keyCount","addr":"(DW)","loc":"d,104:27,104:35","dtypep":"UNLINKED","origName":"keyCount","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(EW)","loc":"d,104:23,104:26","dtypep":"(EW)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"CONST","name":"?32?sh1","addr":"(FW)","loc":"d,104:38,104:39","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []},
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
{"type":"ASSIGN","name":"","addr":"(GW)","loc":"d,105:18,105:20","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"ADD","name":"","addr":"(HW)","loc":"d,105:18,105:20","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(IW)","loc":"d,105:7,105:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"PARSEREF","name":"keyCount","addr":"(JW)","loc":"d,105:21,105:29","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(KW)","loc":"d,105:7,105:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []}
],"scopeNamep": []},
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
{"type":"TASK","name":"get","addr":"(LW)","loc":"d,108:10,108:13","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"get","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"keyCount","addr":"(MW)","loc":"d,108:18,108:26","dtypep":"UNLINKED","origName":"keyCount","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(NW)","loc":"d,108:14,108:17","dtypep":"(NW)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"CONST","name":"?32?sh1","addr":"(OW)","loc":"d,108:29,108:30","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"try_get","addr":"(PW)","loc":"d,117:18,117:25","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"try_get",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(QW)","loc":"d,117:14,117:17","dtypep":"(QW)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"keyCount","addr":"(RW)","loc":"d,117:30,117:38","dtypep":"UNLINKED","origName":"keyCount","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(SW)","loc":"d,117:26,117:29","dtypep":"(SW)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"CONST","name":"?32?sh1","addr":"(TW)","loc":"d,117:41,117:42","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []},
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
{"type":"IF","name":"","addr":"(UW)","loc":"d,118:7,118:9",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"condp": [
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
{"type":"GTE","name":"","addr":"(VW)","loc":"d,118:22,118:24","dtypep":"(YE)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(WW)","loc":"d,118:11,118:21","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"PARSEREF","name":"keyCount","addr":"(XW)","loc":"d,118:25,118:33","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"thensp": [
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
{"type":"BEGIN","name":"","addr":"(YW)","loc":"d,118:35,118:40","implied":false,"needProcess":false,"unnamed":true,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"ASSIGN","name":"","addr":"(ZW)","loc":"d,119:20,119:22","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"SUB","name":"","addr":"(AX)","loc":"d,119:20,119:22","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(BX)","loc":"d,119:9,119:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"PARSEREF","name":"keyCount","addr":"(CX)","loc":"d,119:23,119:31","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],
"lhsp": [
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
{"type":"PARSEREF","name":"m_keyCount","addr":"(DX)","loc":"d,119:9,119:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []},
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
{"type":"RETURN","name":"","addr":"(EX)","loc":"d,120:9,120:15",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh1","addr":"(FX)","loc":"d,120:16,120:17","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
],"elsesp": []},
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
{"type":"RETURN","name":"","addr":"(GX)","loc":"d,122:7,122:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(HX)","loc":"d,122:14,122:15","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
],"extendsp": []},
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
{"type":"CLASS","name":"process","addr":"(IX)","loc":"d,126:3,126:8","isExtended":false,"isInterfaceClass":false,"isVirtual":false,"origName":"process","level":5,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"NONE","classOrPackagep":"UNLINKED","inlinesp": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"TYPEDEF","name":"state","addr":"(JX)","loc":"d,133:7,133:12","dtypep":"UNLINKED","attrPublic":false,"isUnderClass":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"DEFIMPLICITDTYPE","name":"__typeimpenum0","addr":"(KX)","loc":"d,127:13,127:17","dtypep":"UNLINKED","generic":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"ENUMDTYPE","name":"","addr":"(LX)","loc":"d,127:13,127:17","dtypep":"UNLINKED","enum":true,"generic":false,"refDTypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"int","addr":"(MX)","loc":"d,127:18,127:19","dtypep":"(MX)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"itemsp": [
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
{"type":"ENUMITEM","name":"FINISHED","addr":"(NX)","loc":"d,128:7,128:15","dtypep":"UNLINKED","rangep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"valuep": [
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
{"type":"CONST","name":"?32?sh0","addr":"(OX)","loc":"d,128:18,128:19","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
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
{"type":"ENUMITEM","name":"RUNNING","addr":"(PX)","loc":"d,129:7,129:14","dtypep":"UNLINKED","rangep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"valuep": [
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
{"type":"CONST","name":"?32?sh1","addr":"(QX)","loc":"d,129:17,129:18","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
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
{"type":"ENUMITEM","name":"WAITING","addr":"(RX)","loc":"d,130:7,130:14","dtypep":"UNLINKED","rangep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"valuep": [
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
{"type":"CONST","name":"?32?sh2","addr":"(SX)","loc":"d,130:17,130:18","dtypep":"(UD)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
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
{"type":"ENUMITEM","name":"SUSPENDED","addr":"(TX)","loc":"d,131:7,131:16","dtypep":"UNLINKED","rangep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"valuep": [
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
{"type":"CONST","name":"?32?sh3","addr":"(UX)","loc":"d,131:19,131:20","dtypep":"(UD)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
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
{"type":"ENUMITEM","name":"KILLED","addr":"(VX)","loc":"d,132:7,132:13","dtypep":"UNLINKED","rangep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"valuep": [
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
{"type":"CONST","name":"?32?sh4","addr":"(WX)","loc":"d,132:16,132:17","dtypep":"(XX)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
]}
],"attrsp": []},
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
{"type":"FUNC","name":"self","addr":"(YX)","loc":"d,140:29,140:33","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"self",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"REFDTYPE","name":"process","addr":"(ZX)","loc":"d,140:21,140:28","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"p","addr":"(AY)","loc":"d,141:15,141:16","dtypep":"UNLINKED","origName":"p","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"process","addr":"(BY)","loc":"d,141:7,141:14","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],
"valuep": [
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
{"type":"NEW","name":"new","addr":"(CY)","loc":"d,141:19,141:22","dtypep":"UNLINKED","isImplicit":false,"isScoped":false,"dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"attrsp": []},
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
{"type":"RETURN","name":"","addr":"(DY)","loc":"d,145:7,145:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"p","addr":"(EY)","loc":"d,145:14,145:15","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"set_status","addr":"(FY)","loc":"d,148:29,148:39","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"set_status","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"s","addr":"(GY)","loc":"d,148:46,148:47","dtypep":"UNLINKED","origName":"s","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"state","addr":"(HY)","loc":"d,148:40,148:45","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"status","addr":"(IY)","loc":"d,154:20,154:26","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"status",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"REFDTYPE","name":"state","addr":"(JY)","loc":"d,154:14,154:19","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"RETURN","name":"","addr":"(KY)","loc":"d,158:7,158:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"RUNNING","addr":"(LY)","loc":"d,158:14,158:21","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"kill","addr":"(MY)","loc":"d,162:19,162:23","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"kill","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"STMTEXPR","name":"","addr":"(NY)","loc":"d,163:7,163:17",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"TASKREF","name":"set_status","addr":"(OY)","loc":"d,163:7,163:17","dtypep":"(VT)","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"pinsp": [
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
{"type":"ARG","name":"","addr":"(PY)","loc":"d,163:18,163:24",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"PARSEREF","name":"KILLED","addr":"(QY)","loc":"d,163:18,163:24","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"suspend","addr":"(RY)","loc":"d,166:19,166:26","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"suspend","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"DISPLAY","name":"","addr":"(SY)","loc":"d,167:7,167:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fmtp": [
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
{"type":"SFORMATF","name":"","addr":"(TY)","loc":"d,167:7,167:13","dtypep":"(FG)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprsp": [
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
{"type":"CONST","name":"296'h7374643a3a70726f636573733a3a73757370656e642829206e6f7420737570706f72746564","addr":"(UY)","loc":"d,167:14,167:53","dtypep":"(VY)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"scopeNamep": []}
],"filep": []},
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
{"type":"STOP","name":"","addr":"(WY)","loc":"d,167:7,167:13","isFatal":false}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"scopeNamep": []},
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
{"type":"TASK","name":"resume","addr":"(XY)","loc":"d,170:19,170:25","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"resume","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"STMTEXPR","name":"","addr":"(YY)","loc":"d,171:7,171:17",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"TASKREF","name":"set_status","addr":"(ZY)","loc":"d,171:7,171:17","dtypep":"(VT)","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"pinsp": [
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
{"type":"ARG","name":"","addr":"(AZ)","loc":"d,171:18,171:25",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"PARSEREF","name":"RUNNING","addr":"(BZ)","loc":"d,171:18,171:25","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"await","addr":"(CZ)","loc":"d,174:10,174:15","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"await","fvarp": [],"classOrPackagep": [],"stmtsp": [],"scopeNamep": []},
{"type":"TASK","name":"killQueue","addr":"(DZ)","loc":"d,180:17,180:26","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"killQueue","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"processQueue","addr":"(EZ)","loc":"d,180:39,180:51","dtypep":"UNLINKED","origName":"processQueue","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"REF","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BRACKETARRAYDTYPE","name":"","addr":"(FZ)","loc":"d,180:51,180:52","dtypep":"UNLINKED","generic":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"REFDTYPE","name":"process","addr":"(GZ)","loc":"d,180:31,180:38","dtypep":"UNLINKED","generic":false,"typedefp":"UNLINKED","refDTypep":"UNLINKED","classOrPackagep":"UNLINKED","typeofp": [],"classOrPackageOpp": [],"paramsp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"elementsp": [
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
{"type":"UNBOUNDED","name":"","addr":"(HZ)","loc":"d,180:52,180:53","dtypep":"(NS)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
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
{"type":"FUNC","name":"get_randstate","addr":"(IZ)","loc":"d,227:21,227:34","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"get_randstate",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"string","addr":"(JZ)","loc":"d,227:14,227:20","dtypep":"(JZ)","keyword":"string","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"VAR","name":"s","addr":"(KZ)","loc":"d,228:14,228:15","dtypep":"UNLINKED","origName":"s","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"NONE","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"VAR","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"string","addr":"(LZ)","loc":"d,228:7,228:13","dtypep":"(LZ)","keyword":"string","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"STMTEXPR","name":"","addr":"(MZ)","loc":"d,230:8,230:9",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"DOT","name":"","addr":"(NZ)","loc":"d,230:8,230:9","dtypep":"UNLINKED","colon":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"s","addr":"(OZ)","loc":"d,230:7,230:8","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"TASKREF","name":"itoa","addr":"(PZ)","loc":"d,230:9,230:13","dtypep":"(VT)","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"pinsp": [
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
{"type":"ARG","name":"","addr":"(QZ)","loc":"d,230:14,230:21",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"RAND","name":"","addr":"(RZ)","loc":"d,230:14,230:21","dtypep":"UNLINKED","seedp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
]},
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
{"type":"STMTEXPR","name":"","addr":"(SZ)","loc":"d,231:7,231:20",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"TASKREF","name":"set_randstate","addr":"(TZ)","loc":"d,231:7,231:20","dtypep":"(VT)","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"pinsp": [
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
{"type":"ARG","name":"","addr":"(UZ)","loc":"d,231:21,231:22",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
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
{"type":"PARSEREF","name":"s","addr":"(VZ)","loc":"d,231:21,231:22","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]},
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
{"type":"RETURN","name":"","addr":"(WZ)","loc":"d,232:7,232:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"s","addr":"(XZ)","loc":"d,232:14,232:15","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
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
{"type":"TASK","name":"set_randstate","addr":"(YZ)","loc":"d,235:19,235:32","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"set_randstate","fvarp": [],"classOrPackagep": [],
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"stmtsp": [
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
{"type":"VAR","name":"s","addr":"(ZZ)","loc":"d,235:40,235:41","dtypep":"UNLINKED","origName":"s","isSc":false,"isPrimaryIO":false,"isPrimaryClock":false,"direction":"INPUT","isConst":false,"isPullup":false,"isPulldown":false,"isSigPublic":false,"isLatched":false,"isUsedLoopIdx":false,"noReset":false,"attrIsolateAssign":false,"attrFileDescr":false,"isDpiOpenArray":false,"isFuncReturn":false,"isFuncLocal":false,"lifetime":"NONE","varType":"PORT","isSigUserRdPublic":false,"isSigUserRWPublic":false,"isGParam":false,"isParam":false,"attrScBv":false,"attrSFormat":false,"ignorePostWrite":false,"ignoreSchedWrite":false,"sensIfacep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
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
{"type":"BASICDTYPE","name":"string","addr":"(AAB)","loc":"d,235:33,235:39","dtypep":"(AAB)","keyword":"string","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"delayp": [],"valuep": [],"attrsp": []},
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
{"type":"STMTEXPR","name":"","addr":"(BAB)","loc":"d,236:7,236:15",
Internals: Remove AstSysFuncAsTask
2025-08-08 11:09:54 +02:00
"exprp": [
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
{"type":"RAND","name":"","addr":"(CAB)","loc":"d,236:7,236:15","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"seedp": [
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
{"type":"DOT","name":"","addr":"(DAB)","loc":"d,236:17,236:18","dtypep":"UNLINKED","colon":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
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
{"type":"PARSEREF","name":"s","addr":"(EAB)","loc":"d,236:16,236:17","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"rhsp": [
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
{"type":"FUNCREF","name":"atoi","addr":"(FAB)","loc":"d,236:18,236:22","dtypep":"UNLINKED","dotted":"","taskp":"UNLINKED","classOrPackagep":"UNLINKED","namep": [],"pinsp": [],"scopeNamep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
]}
]}
],"scopeNamep": []}
],"extendsp": []},
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
{"type":"FUNC","name":"randomize","addr":"(GAB)","loc":"d,239:16,239:25","dtypep":"UNLINKED","method":false,"dpiExport":false,"dpiImport":false,"dpiOpenChild":false,"dpiOpenParent":false,"isExternDef":false,"isExternProto":false,"prototype":false,"recursive":false,"taskPublic":false,"cname":"randomize",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fvarp": [
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
{"type":"BASICDTYPE","name":"int","addr":"(HAB)","loc":"d,239:12,239:15","dtypep":"(HAB)","keyword":"int","range":"31:0","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
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
{"type":"ASSIGN","name":"","addr":"(IAB)","loc":"d,240:15,240:16","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
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
{"type":"CONST","name":"?32?sh0","addr":"(JAB)","loc":"d,240:17,240:18","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"lhsp": [
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
{"type":"PARSEREF","name":"randomize","addr":"(KAB)","loc":"d,240:5,240:14","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"timingControlp": []}
],"scopeNamep": []}
Internals: Remove unused AstNodeModule 'activesp' child (#6138)
2025-06-29 15:56:44 +02:00
]}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
],"filesp": [],
"miscsp": [
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
{"type":"TYPETABLE","name":"","addr":"(C)","loc":"a,0:0,0:0","constraintRefp":"UNLINKED","emptyQueuep":"UNLINKED","queueIndexp":"UNLINKED","streamp":"UNLINKED","voidp":"(VT)",
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"typesp": [
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
{"type":"BASICDTYPE","name":"integer","addr":"(NS)","loc":"d,36:25,36:26","dtypep":"(NS)","keyword":"integer","range":"31:0","generic":true,"rangep": []},
Internals: Reformat verilated_std.sv. No functional change.
2025-09-13 15:10:37 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(N)","loc":"d,38:30,38:31","dtypep":"(N)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
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
{"type":"BASICDTYPE","name":"logic","addr":"(YE)","loc":"d,55:19,55:21","dtypep":"(YE)","keyword":"logic","generic":true,"rangep": []},
{"type":"VOIDDTYPE","name":"","addr":"(VT)","loc":"d,56:17,56:26","dtypep":"(VT)","generic":false},
{"type":"BASICDTYPE","name":"logic","addr":"(UD)","loc":"d,130:17,130:18","dtypep":"(UD)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(XX)","loc":"d,132:16,132:17","dtypep":"(XX)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(VY)","loc":"d,167:14,167:53","dtypep":"(VY)","keyword":"logic","range":"295:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"string","addr":"(FG)","loc":"d,167:7,167:13","dtypep":"(FG)","keyword":"string","generic":true,"rangep": []},
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(S)","loc":"e,14:9,14:11","dtypep":"(S)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(DB)","loc":"e,18:10,18:12","dtypep":"(DB)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
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
{"type":"BASICDTYPE","name":"logic","addr":"(QC)","loc":"e,33:26,33:31","dtypep":"(QC)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(NC)","loc":"e,33:25,33:26","dtypep":"(NC)","keyword":"logic","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(EF)","loc":"e,45:17,45:38","dtypep":"(EF)","keyword":"logic","range":"63:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(NF)","loc":"e,48:22,48:24","dtypep":"(NF)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(WF)","loc":"e,51:22,51:24","dtypep":"(WF)","keyword":"logic","range":"31:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(HG)","loc":"e,54:17,54:49","dtypep":"(HG)","keyword":"logic","range":"231:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"QData","addr":"(JG)","loc":"e,54:51,54:56","dtypep":"(JG)","keyword":"QData","range":"63:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"logic","addr":"(AH)","loc":"e,59:17,59:41","dtypep":"(AH)","keyword":"logic","range":"167:0","generic":true,"rangep": []}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]},
{"type":"CONSTPOOL","name":"","addr":"(D)","loc":"a,0:0,0:0",
"modulep": [
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
{"type":"MODULE","name":"@CONST-POOL@","addr":"(LAB)","loc":"a,0:0,0:0","isChecker":false,"isProgram":false,"hasGenericIface":false,"origName":"@CONST-POOL@","level":0,"modPublic":false,"inLibrary":false,"dead":false,"recursiveClone":false,"recursive":false,"timeunit":"NONE","inlinesp": [],
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
"stmtsp": [
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
{"type":"SCOPE","name":"@CONST-POOL@","addr":"(MAB)","loc":"a,0:0,0:0","aboveScopep":"UNLINKED","aboveCellp":"UNLINKED","modp":"(LAB)","varsp": [],"blocksp": [],"inlinesp": []}
Internals: Remove unused AstNodeModule 'activesp' child (#6138)
2025-06-29 15:56:44 +02:00
]}
Add JSON AST dumps (#5020)
2024-03-28 12:32:18 +01:00
]}
]}