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_timing_debug1.out

4198 lines
258 KiB
Plaintext
Raw Normal View History

Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}- Verilated::debug is on. Message prefix indicates {<thread>,<sequence_number>}.
-V{t#,#}+ Vt_timing_debug1___024root___ctor_var_reset
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Initial
-V{t#,#}+ Vt_timing_debug1___024root___eval_static
-V{t#,#}+ Vt_timing_debug1___024root___eval_static__TOP
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_initial
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_initial__TOP__Vtiming__0
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:18
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_initial__TOP__Vtiming__1
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_initial__TOP__Vtiming__2
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:48
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_initial__TOP__Vtiming__3
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_settle
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__stl
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__stl
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__stl
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
Internals: Make all scheduling region use a single trigger vector. (#6620) The 'act' region used to have 2 trigger vectors ('act' and 'pre'), now it uses a single "extended" trigger vector where the top bits are what used to be the used bits in the 'pre' trigger vector. Please see the description above `TriggerKit`. Also move the extra triggers from the low end to the high end in the trigger vectors.
2025-11-01 16:43:20 +01:00
-V{t#,#} 'stl' region trigger index 0 is active: @([hybrid] t.clk1)
-V{t#,#} 'stl' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'stl' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'stl' region trigger index 3 is active: @([hybrid] t.clk2)
-V{t#,#} 'stl' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'stl' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'stl' region trigger index 64 is active: Internal 'stl' trigger - first iteration
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_stl
-V{t#,#}+ Vt_timing_debug1___024root___stl_sequent__TOP__0
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__stl
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__stl
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__stl
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
Internals: Make all scheduling region use a single trigger vector. (#6620) The 'act' region used to have 2 trigger vectors ('act' and 'pre'), now it uses a single "extended" trigger vector where the top bits are what used to be the used bits in the 'pre' trigger vector. Please see the description above `TriggerKit`. Also move the extra triggers from the low end to the high end in the trigger vectors.
2025-11-01 16:43:20 +01:00
-V{t#,#} 'stl' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'stl' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'stl' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'stl' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_stl
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__stl
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__stl
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__stl
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
-V{t#,#} No 'stl' region triggers active
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__stl
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 3: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 11: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:18
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 6: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 7: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 11: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 7: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 9: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 11: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 9: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 11: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 11: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 12: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 13: Process waiting at t/t_timing_sched.v:17
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 8 is active: @(posedge t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk2):
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
-V{t#,#} Awaiting time 12: Process waiting at t/t_timing_sched.v:10
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Awaiting time 12: Process waiting at t/t_timing_sched.v:48
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 13: Process waiting at t/t_timing_sched.v:17
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 13: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 15: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 15: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:18
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 18: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 19: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 19: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 21: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 21: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 22: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 24: Process waiting at t/t_timing_sched.v:10
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 25: Process waiting at t/t_timing_sched.v:17
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 24: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 25: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 25: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 27: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 27: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 31: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 31: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:10
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 33: Process waiting at t/t_timing_sched.v:10
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Committing processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
-V{t#,#} 'act' region trigger index 8 is active: @(posedge t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Awaiting time 34: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 36: Process waiting at t/t_timing_sched.v:10
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 37: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 36: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 37: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 37: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 39: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 39: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:18
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 42: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 43: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 43: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 45: Process waiting at t/t_timing_sched.v:10
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 44: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 45: Process waiting at t/t_timing_sched.v:10
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 45: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 48: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 49: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 49: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 51: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 51: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 54: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:17
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:13
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 57: Process waiting at t/t_timing_sched.v:10
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 8 is active: @(posedge t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Awaiting time 56: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 57: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 57: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk2) at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 61: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 61: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 63: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 63: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 66: Process waiting at t/t_timing_sched.v:10
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 67: Process waiting at t/t_timing_sched.v:17
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 67: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 69: Process waiting at t/t_timing_sched.v:10
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 69: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 72: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 73: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 73: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 75: Process waiting at t/t_timing_sched.v:10
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 75: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 6 is active: @(posedge t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Processes to resume waiting for @(posedge t.clk1):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:17
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___nba_sequent__TOP__0
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 77: Process waiting at t/t_timing_sched.v:13
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 79: Process waiting at t/t_timing_sched.v:17
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:13
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#} Committing processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 3 is active: @([hybrid] t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 8 is active: @(posedge t.clk2)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @(posedge t.clk2):
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:48
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @(posedge t.clk2):
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:18
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root____VbeforeTrig_h########__0
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Suspending process waiting for @(posedge t.clk1) at t/t_timing_sched.v:18
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1____Vfork_2__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 4 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 5 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__1
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__1
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+++++TOP Evaluate Vt_timing_debug1::eval_step
-V{t#,#}+ Vt_timing_debug1___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug1___024root___eval
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} 'act' region trigger index 7 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:51
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:10
-V{t#,#} Awaiting time 78: Process waiting at t/t_timing_sched.v:48
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 79: Process waiting at t/t_timing_sched.v:17
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Awaiting time 88: Process waiting at t/t_timing_sched.v:13
-V{t#,#} Resuming delayed processes
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:51
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
*-* All Finished *-*
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:10
Optimize complex combinational logic in DFG (#6298) This patch adds DfgLogic, which is a vertex that represents a whole, arbitrarily complex combinational AstAlways or AstAssignW in the DfgGraph. Implementing this requires computing the variables live at entry to the AstAlways (variables read by the block), so there is a new ControlFlowGraph data structure and a classical data-flow analysis based live variable analysis to do that at the variable level (as opposed to bit/element level). The actual CFG construction and live variable analysis is best effort, and might fail for currently unhandled constructs or data types. This can be extended later. V3DfgAstToDfg is changed to convert the Ast into an initial DfgGraph containing only DfgLogic, DfgVertexSplice and DfgVertexVar vertices. The DfgLogic are then subsequently synthesized into primitive operations by the new V3DfgSynthesize pass, which is a combination of the old V3DfgAstToDfg conversion and new code to handle AstAlways blocks with complex flow control. V3DfgSynthesize by default will synthesize roughly the same constructs as V3DfgAstToDfg used to handle before, plus any logic that is part of a combinational cycle within the DfgGraph. This enables breaking up these cycles, for which there are extensions to V3DfgBreakCycles in this patch as well. V3DfgSynthesize will then delete all non synthesized or non synthesizable DfgLogic vertices and the rest of the Dfg pipeline is identical, with minor changes to adjust for the changed representation. Because with this change we can now eliminate many more UNOPTFLAT, DFG has been disabled in all the tests that specifically target testing the scheduling and reporting of circular combinational logic.
2025-08-19 16:06:38 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_sched.v:48
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([hybrid] t.clk1)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0____Vfork_1__0
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Generate one trigger per SenItem instead of per SenTree (#5483)
2024-09-25 11:35:50 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([hybrid] __VassignWtmp_h########__0)
-V{t#,#} 'act' region trigger index 2 is active: @([hybrid] __VassignWgen_h########__0)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @(posedge t.clk1)
-V{t#,#} Not triggered processes waiting for @(posedge t.clk1):
-V{t#,#} - Process waiting at t/t_timing_sched.v:18
-V{t#,#} Resuming processes waiting for @(posedge t.clk1)
-V{t#,#} No process to resume waiting for @(posedge t.clk2)
-V{t#,#} Resuming processes waiting for @(posedge t.clk2)
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_act
-V{t#,#}+ Vt_timing_debug1___024root___act_sequent__TOP__0
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Support IEEE-compliant intra-assign delays (#3711) (#5441)
2024-09-07 00:13:52 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_nba
-V{t#,#}+ Vt_timing_debug1___024root___act_comb__TOP__0
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_clear__act
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_triggers_vec__act
-V{t#,#}+ Vt_timing_debug1___024root___timing_ready
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___dump_triggers__act
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_orInto__act_vec_vec
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Support #0 delays with IEEE-1800 compliant semantics (#7079) This patch adds IEEE-1800 compliant scheduling support for the Inactive scheduling region used for #0 delays. Implementing this requires that **all** IEEE-1800 active region events are placed in the internal 'act' section. This has simulation performance implications. It prevents some optimizations (e.g. V3LifePost), which reduces single threaded performance. It also reduces the available work and parallelism in the internal 'nba' section, which reduced the effectiveness of multi-threading severely. Performance impact on RTLMeter when using scheduling adjusted to support proper #0 delays is ~10-20% slowdown in single-threaded mode, and ~100% (2x slower) with --threads 4. To avoid paying this performance penalty unconditionally, the scheduling is only adjusted if either: 1. The input contains a statically known #0 delay 2. The input contains a variable #x delay unknown at compile time If no #0 is present, but #x variable delays are, a ZERODLY warning is issued advising the use of '--no-sched-zero-delay' which is a promise by the user that none of the variable delays will evaluate to a zero delay at run-time. This warning is turned off if '--sched-zero-delay' is explicitly given. This is similar to the '--timing' option. If '--no-sched-zero-delay' was used at compile time, then executing a zero delay will fail at runtime. A ZERODLY warning is also issued if a static #0 if found, but the user specified '--no-sched-zero-delay'. In this case the scheduling is not adjusted to support #0, so executing it will fail at runtime. Presumably the user knows it won't be executed. The intended behaviour with all this is the following: No #0, no #var in the design (#constant is OK) -> Same as current behaviour, scheduling not adjusted, same code generated as before Has static #0 and '--no-sched-zero-delay' is NOT given: -> No warnings, scheduling adjusted so it just works, runs slow Has static #0 and '--no-sched-zero-delay' is given: -> ZERODLY on the #0, scheduling not adjusted, fails at runtime if hit No static #0, but has #var and no option is given: -> ZERODLY on the #var advising use of '--no-sched-zero-delay' or '--sched-zero-delay' (similar to '--timing'), scheduling adjusted assuming it can be a zero delay and it just works No static #0, but has #var and '--no-sched-zero-delay' is given: -> No warning, scheduling not adjusted, fails at runtime if zero delay No static #0, but has #var and '--sched-zero-delay' is given: -> No warning, scheduling adjusted so it just works
2026-02-16 04:55:55 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__inact
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_phase__nba
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug1___024root___trigger_anySet__act
Remove --no-threads; require --threads 1 for single threaded (#3703).
2022-11-05 13:47:34 +01:00
-V{t#,#}End-of-eval cleanup
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug1___024root___eval_final