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

1759 lines
123 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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(ZC)","loc":"e,36:27,36:32","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(BF)","loc":"e,43:21,43:26","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(OF)","loc":"e,48:26,48:31","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(XF)","loc":"e,51:26,51:31","implied":false,"needProcess":false,"unnamed":true,"declsp": [],"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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(CG)","loc":"e,53:27,53:32","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(WH)","loc":"e,82:26,82:31","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"blk","addr":"(RI)","loc":"e,91:7,91:12","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(VI)","loc":"e,95:12,95:17","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
Internals: fix assertion type dumping (#6523)
2025-10-02 18:03:45 +02:00
"stmtsp": [
Internals: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_simple_immediate_else","addr":"(WI)","loc":"e,96:7,96:35","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_simple_immediate_stmt","addr":"(CJ)","loc":"e,97:7,97:35","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_simple_immediate_stmt_else","addr":"(IJ)","loc":"e,98:7,98:40","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_simple_immediate","addr":"(RJ)","loc":"e,100:7,100:30","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_simple_immediate_else","addr":"(UJ)","loc":"e,101:7,101:35","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_simple_immediate_stmt","addr":"(AK)","loc":"e,102:7,102:35","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_simple_immediate_stmt_else","addr":"(GK)","loc":"e,103:7,103:40","implied":false,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_observed_deferred_immediate","addr":"(QK)","loc":"e,106:4,106:38","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_observed_deferred_immediate_else","addr":"(UK)","loc":"e,107:4,107:43","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_observed_deferred_immediate_stmt","addr":"(BL)","loc":"e,108:4,108:43","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +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,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_observed_deferred_immediate","addr":"(SL)","loc":"e,111:4,111:38","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_observed_deferred_immediate_else","addr":"(WL)","loc":"e,112:4,112:43","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_observed_deferred_immediate_stmt","addr":"(DM)","loc":"e,113:4,113:43","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +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,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_final_deferred_immediate","addr":"(UM)","loc":"e,116:4,116:35","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_final_deferred_immediate_else","addr":"(YM)","loc":"e,117:4,117:40","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_final_deferred_immediate_stmt","addr":"(FN)","loc":"e,118:4,118:40","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +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,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_final_deferred_immediate","addr":"(WN)","loc":"e,121:4,121:35","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_final_deferred_immediate_else","addr":"(AO)","loc":"e,122:4,122:40","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_final_deferred_immediate_stmt","addr":"(HO)","loc":"e,123:4,123:40","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +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,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_concurrent","addr":"(CP)","loc":"e,130:4,130:21","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_concurrent_else","addr":"(HP)","loc":"e,131:4,131:26","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_concurrent_stmt","addr":"(PP)","loc":"e,132:4,132:26","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assert_concurrent_stmt_else","addr":"(XP)","loc":"e,133:4,133:31","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_concurrent","addr":"(IQ)","loc":"e,135:4,135:21","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_concurrent_else","addr":"(NQ)","loc":"e,136:4,136:26","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_concurrent_stmt","addr":"(VQ)","loc":"e,137:4,137:26","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"assume_concurrent_stmt_else","addr":"(DR)","loc":"e,138:4,138:31","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"cover_concurrent","addr":"(OR)","loc":"e,140:4,140:20","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"cover_concurrent_stmt","addr":"(SR)","loc":"e,141:4,141:25","implied":true,"needProcess":false,"unnamed":false,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(QT)","loc":"d,55:44,55:49","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(NU)","loc":"d,72:22,72:27","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(IV)","loc":"d,89:22,89:27","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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: Refactor AstNodeBlock representation (#6280) (#6588) Internals: Refactor AstNodeBlock representation (#6280) AstNodeBlock now has 2 child lists: 'declsp' to hold declarations within the block, and 'stmtsp' to hold the procedural statements. AstBegin is then just a simple subtype of AstNodeBlock. AstFork is a proper superset of AstNodeBlock (and also AstBegin), and adds 'forksp' which hold the parallel statements. Having the sequential 'stmtsp' in AstFork is required to properly implement variable initializers in fork blocks (IEEE 1800-2023 9.3.2), this makes that clear, while also separating the non AstNodeStmt declarations (for #6280). The actual fork branches in 'AstFork::forkps()' are all AstBegin nodes. This is required as lowering stages will introduce additional statements in each parallel branch. (We used to wrap AstFork statements into AstBegin in 3 different places, now they always are AstBegin and this is enforced via the type checker/V3Broken). Also fixes incorrect disabling of forked processes from within the `fork`.
2025-10-24 15:00:07 +02:00
{"type":"BEGIN","name":"","addr":"(YW)","loc":"d,118:35,118:40","implied":false,"needProcess":false,"unnamed":true,"declsp": [],
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": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"m_process","addr":"(YX)","loc":"d,136:23,136:32","dtypep":"UNLINKED","origName":"m_process","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",
"childDTypep": [
{"type":"BASICDTYPE","name":"chandle","addr":"(ZX)","loc":"d,136:15,136:22","dtypep":"(ZX)","keyword":"chandle","range":"63:0","generic":false,"rangep": []}
],"delayp": [],"valuep": [],"attrsp": []},
{"type":"FUNC","name":"self","addr":"(AY)","loc":"d,138:29,138: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"REFDTYPE","name":"process","addr":"(BY)","loc":"d,138:21,138: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"p","addr":"(CY)","loc":"d,139:15,139: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"REFDTYPE","name":"process","addr":"(DY)","loc":"d,139:7,139: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"NEW","name":"new","addr":"(EY)","loc":"d,139:19,139: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": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"RETURN","name":"","addr":"(FY)","loc":"d,143:7,143:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"p","addr":"(GY)","loc":"d,143:14,143:15","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"set_status","addr":"(HY)","loc":"d,146:29,146: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"s","addr":"(IY)","loc":"d,146:46,146: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"REFDTYPE","name":"state","addr":"(JY)","loc":"d,146:40,146: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": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"FUNC","name":"status","addr":"(KY)","loc":"d,152:20,152: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"REFDTYPE","name":"state","addr":"(LY)","loc":"d,152:14,152: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"RETURN","name":"","addr":"(MY)","loc":"d,156:7,156:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"RUNNING","addr":"(NY)","loc":"d,156:14,156:21","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"kill","addr":"(OY)","loc":"d,160:19,160: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"STMTEXPR","name":"","addr":"(PY)","loc":"d,161:7,161:17",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASKREF","name":"set_status","addr":"(QY)","loc":"d,161:7,161: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"ARG","name":"","addr":"(RY)","loc":"d,161:18,161:24",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"KILLED","addr":"(SY)","loc":"d,161:18,161:24","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"suspend","addr":"(TY)","loc":"d,164:19,164: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"DISPLAY","name":"","addr":"(UY)","loc":"d,165:7,165:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"fmtp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"SFORMATF","name":"","addr":"(VY)","loc":"d,165:7,165:13","dtypep":"(FG)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"CONST","name":"296'h7374643a3a70726f636573733a3a73757370656e642829206e6f7420737570706f72746564","addr":"(WY)","loc":"d,165:14,165:53","dtypep":"(XY)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"scopeNamep": []}
],"filep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"STOP","name":"","addr":"(YY)","loc":"d,165:7,165:13","isFatal":false}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"resume","addr":"(ZY)","loc":"d,168:19,168: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"STMTEXPR","name":"","addr":"(AZ)","loc":"d,169:7,169:17",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASKREF","name":"set_status","addr":"(BZ)","loc":"d,169:7,169: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"ARG","name":"","addr":"(CZ)","loc":"d,169:18,169:25",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"exprp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"RUNNING","addr":"(DZ)","loc":"d,169:18,169:25","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
]}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"await","addr":"(EZ)","loc":"d,172:10,172: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":"(FZ)","loc":"d,178:17,178: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"processQueue","addr":"(GZ)","loc":"d,178:39,178: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BRACKETARRAYDTYPE","name":"","addr":"(HZ)","loc":"d,178:51,178:52","dtypep":"UNLINKED","generic":false,
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"childDTypep": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"REFDTYPE","name":"process","addr":"(IZ)","loc":"d,178:31,178: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"UNBOUNDED","name":"","addr":"(JZ)","loc":"d,178:52,178:53","dtypep":"(NS)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"delayp": [],"valuep": [],"attrsp": []}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"FUNC","name":"get_randstate","addr":"(KZ)","loc":"d,225:21,225: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BASICDTYPE","name":"string","addr":"(LZ)","loc":"d,225:14,225:20","dtypep":"(LZ)","keyword":"string","generic":false,"rangep": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],"classOrPackagep": [],
"stmtsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"s","addr":"(MZ)","loc":"d,227:14,227: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BASICDTYPE","name":"string","addr":"(NZ)","loc":"d,227:7,227:13","dtypep":"(NZ)","keyword":"string","generic":false,"rangep": []}
],"delayp": [],
"valuep": [
{"type":"CVTPACKSTRING","name":"","addr":"(OZ)","loc":"d,227:18,227:24","dtypep":"(FG)",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"CEXPRUSER","name":"","addr":"(PZ)","loc":"d,227:26,227:28","dtypep":"UNLINKED",
"nodesp": [
{"type":"TEXT","name":"","addr":"(QZ)","loc":"d,227:29,227:32","text":"0"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
]}
],"attrsp": []},
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"CSTMTUSER","name":"","addr":"(RZ)","loc":"d,229:7,229:9",
"nodesp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"s","addr":"(SZ)","loc":"d,229:10,229:11","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"TEXT","name":"","addr":"(TZ)","loc":"d,229:13,229:18","text":" = "},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"m_process","addr":"(UZ)","loc":"d,229:20,229:29","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"TEXT","name":"","addr":"(VZ)","loc":"d,229:31,229:47","text":"->randstate();"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"RETURN","name":"","addr":"(WZ)","loc":"d,230:7,230:13",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"lhsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"s","addr":"(XZ)","loc":"d,230:14,230:15","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"TASK","name":"set_randstate","addr":"(YZ)","loc":"d,233:19,233: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"VAR","name":"s","addr":"(ZZ)","loc":"d,233:40,233: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BASICDTYPE","name":"string","addr":"(AAB)","loc":"d,233:33,233: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: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"CSTMTUSER","name":"","addr":"(BAB)","loc":"d,234:7,234:9",
"nodesp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"m_process","addr":"(CAB)","loc":"d,234:10,234:19","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"TEXT","name":"","addr":"(DAB)","loc":"d,234:21,234:35","text":"->randstate("},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"s","addr":"(EAB)","loc":"d,234:37,234:38","dtypep":"UNLINKED","lhsp": [],"ftaskrefp": []},
Internals: Refactor text based Ast constructs (#6280) (#6571) Remove the large variety of ways raw "text" is represented in the Ast. Particularly, the only thing that represents a string to be emitted in the output is AstText. There are 5 AstNodes that can contain AstText, and V3Emit will throw an error if an AstText is encountered anywhere else: - AstCStmt: Internally generated procedural statements involving raw text. - AstCStmtUser: This is the old AstUCStmt, renamed so it sorts next to AstCStmt, as it's largely equivalent. We should never create this internally unless used to represent user input. It is used for $c, statements in the input, and for some 'systemc_* blocks. - AstCExpr: Internally generaged expression involving raw text. - AstCExprUser: This is the old AstUCFunc, renamed so it sorts next to AstCExpr. It is largely equivalent, but also has more optimizations disabled. This should never be created internally, it is only used for $c expressions in the input. - AstTextBlock: Use by V3ProtectLib only, to generate the hierarchical wrappers. Text "tracking" for indentation is always on for AstCStmt, AstCExpr, and AstTextBlock, as these are always generated by us, and should always be well formed. Tracking is always off for AstCStmtUser and AstCExprUser, as these contain arbitrary user input that might not be safe to parse for indentation. Remove subsequently redundant AstNodeSimpleText and AstNodeText types. This patch also fixes incorrect indentation in emitted waveform tracing functions, and makes the output more readable for hier block SV stubs. With that, all raw text nodes are handled as a proper AstNodeStmt or AstNodeExpr as required for #6280.
2025-10-21 13:41:29 +02:00
{"type":"TEXT","name":"","addr":"(FAB)","loc":"d,234:40,234:44","text":");"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
]}
],"scopeNamep": []}
],"extendsp": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"FUNC","name":"randomize","addr":"(GAB)","loc":"d,238:16,238: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BASICDTYPE","name":"int","addr":"(HAB)","loc":"d,238:12,238: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": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"ASSIGN","name":"","addr":"(IAB)","loc":"d,239:15,239:16","dtypep":"UNLINKED",
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
"rhsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"CONST","name":"?32?sh0","addr":"(JAB)","loc":"d,239:17,239:18","dtypep":"(N)"}
Support disabling a fork from outside that fork (#6174)
2025-07-14 12:51:58 +02:00
],
"lhsp": [
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"PARSEREF","name":"randomize","addr":"(KAB)","loc":"d,239:5,239: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": []},
Fix std::process::get_randstate to not affect random stability (#6550) (#6565)
2025-10-17 03:11:07 +02:00
{"type":"BASICDTYPE","name":"logic","addr":"(XY)","loc":"d,165:14,165:53","dtypep":"(XY)","keyword":"logic","range":"295:0","generic":true,"rangep": []},
{"type":"BASICDTYPE","name":"string","addr":"(FG)","loc":"d,165:7,165: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
]}
]}