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

1711 lines
112 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_debug2___024root___ctor_var_reset
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Initial
-V{t#,#}+ Vt_timing_debug2___024root___eval_static
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t___eval_static__TOP__t
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::_ctor_var_reset
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::_ctor_var_reset
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::_ctor_var_reset
Support proper automatic/static initialization, and remove STATICVAR warning (#6405). (#7086)
2026-02-24 20:04:43 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___eval_initial
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__0
-V{t#,#}+ Vt_timing_debug2___024root____VbeforeTrig_h########__0
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Suspending process waiting for @([event] t.ec.e) at t/t_timing_class.v:115
Support proper automatic/static initialization, and remove STATICVAR warning (#6405). (#7086)
2026-02-24 20:04:43 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__1
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__2
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__3
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__4
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_count_5
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:101
Support proper automatic/static initialization, and remove STATICVAR warning (#6405). (#7086)
2026-02-24 20:04:43 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__5
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__6
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::__VnoInFunc_do_delay
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__7
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::__VnoInFunc_do_fork
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::__VnoInFunc_do_fork____Vfork_1__0
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::__VnoInFunc_do_fork____Vfork_1__1
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::__VnoInFunc_do_fork____Vfork_1__1____Vfork_2__0
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass::__VnoInFunc_do_fork____Vfork_1__1____Vfork_2__1
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting join of fork at: t/t_timing_class.v:259
-V{t#,#} Awaiting join of fork at: t/t_timing_class.v:254
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__8
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__9
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_settle
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:101
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-05 12:36:10 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:101
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 5: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:176
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:256
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:123
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:261
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:101
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:101 awaiting resumption
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 10: Process waiting at t/t_timing_class.v:176
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:256
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:123
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:261
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:176
Optimize away calls to empty functions (#6626)
2025-11-02 22:11:02 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::__VnoInFunc_do_sth_else
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::__VnoInFunc_do_delay
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:256
-V{t#,#} Process forked at t/t_timing_class.v:255 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-05 12:36:10 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-05 12:36:10 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-05 12:36:10 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-05 12:36:10 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 15: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:123
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:261
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:177
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:102 awaiting resumption
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:102
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:102
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Not triggered processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 20: Process waiting at t/t_timing_class.v:123
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:261
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:177
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:123
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_wake
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:261
-V{t#,#} Process forked at t/t_timing_class.v:260 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#} Committing processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 0 is active: @([event] t.ec.e)
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Moving to resume queue processes waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} Processes to resume waiting for @([event] t.ec.e):
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:115
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:115
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_sleep
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_nba
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t___nba_sequent__TOP__t__0
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_inc_trig_count
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 25: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:177
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:103 awaiting resumption
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:103
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:103
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 30: Process waiting at t/t_timing_class.v:266
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:177
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:266
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkDelayClass::__VnoInFunc_do_delay
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:177
Optimize away calls to empty functions (#6626)
2025-11-02 22:11:02 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::__VnoInFunc_do_sth_else
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::__VnoInFunc_do_delay
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 35: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:104 awaiting resumption
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:104
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:104
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} No 'act' region triggers active
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:124
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:124
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting the post update step
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Doing post updates for processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:40 awaiting resumption
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
-V{t#,#}+ Vt_timing_debug2___024root___dump_triggers__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__act
-V{t#,#} 'act' region trigger index 0 is active: @([event] t.ec.e)
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:40
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:40
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_inc_trig_count
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass::__VnoInFunc_await
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_nba
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t___nba_sequent__TOP__t__0
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_inc_trig_count
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular AstCFunc if needed. No functional change intended, performance should be the same.
2025-10-31 19:29:11 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 45: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:105 awaiting resumption
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:105
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:105
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 50: Process waiting at t/t_timing_class.v:126
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:126
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 55: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_class.v:127
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_class.v:127
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:127
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
-V{t#,#} Process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:61 awaiting resumption
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:61
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:61
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::__VnoInFunc_await
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::__VnoInFunc_await____Vfork_1__0
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix duplicate Vfork functions (#4418)
2023-08-30 23:59:25 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::__VnoInFunc_await____Vfork_1__1
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting join of fork at: t/t_timing_class.v:77
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 65: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:79
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:246
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:178
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:79
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:246
-V{t#,#} Process forked at t/t_timing_class.v:265 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:259
-V{t#,#} Process forked at t/t_timing_class.v:259 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:254
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:178
Optimize away calls to empty functions (#6626)
2025-11-02 22:11:02 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::__VnoInFunc_do_sth_else
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::__VnoInFunc_do_delay
Optimize away calls to empty functions (#6626)
2025-11-02 22:11:02 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::__VnoInFunc_do_sth_else
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__6____Vfork_1__0
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::__VnoInFunc_do_assign
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:79
-V{t#,#} Process forked at t/t_timing_class.v:79 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:227
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:78 awaiting resumption
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} Resuming processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} - Process waiting at t/t_timing_class.v:78
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:78
-V{t#,#} Process forked at t/t_timing_class.v:78 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:77
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 75: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 75: Process waiting at t/t_timing_class.v:228
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:193
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:228
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 80: Process waiting at t/t_timing_class.v:140
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:193
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:140
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:193
Fix conflicted namespace for coroutines (#4701) (#4707)
2023-11-21 03:02:10 +01:00
-V{t#,#}+ Vt_timing_debug2_t___eval_initial__TOP__t__Vtiming__6____Vfork_2__0
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:234
Fix fork scheduling semantics (#6730) Signed-off-by: Artur Bieniek <abieniek@internships.antmicro.com>
2025-11-26 13:52:53 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::__VnoInFunc_do_assign
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 85: Process waiting at t/t_timing_class.v:237
-V{t#,#} Awaiting time 85: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 90: Process waiting at t/t_timing_class.v:193
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:237
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 90: Process waiting at t/t_timing_class.v:193
-V{t#,#} Awaiting time 90: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:193
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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 95: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-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_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}End-of-eval cleanup
-V{t#,#}+++++TOP Evaluate Vt_timing_debug2::eval_step
-V{t#,#}+ Vt_timing_debug2___024root___eval_debug_assertions
-V{t#,#}+ Eval
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___024root___trigger_orInto__act_vec_vec
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} 'act' region trigger index 1 is active: @([true] __VdlySched.awaitingCurrentTime())
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___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_debug2___024root___trigger_anySet__act
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_resume
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#} No process to resume waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#} Delayed processes:
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:135
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:283
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:238
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
*-* All Finished *-*
Tests: Verilog format
2026-03-10 02:38:29 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:135
Fix multiple edge timing controls in class methods (#4318) (#4320) (#4344) Multiple edge timing controls in class methods would cause compilation errors on the generated C++ code. This is because the `SenExprBuilder` used for these would get recreated per timing control, resulting in duplicate variable names. The fix is to have a single `SenExprBuilder` per scope.
2023-07-07 14:19:49 +02:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aClkClass::__VnoInFunc_flip
Make eval loop construction more unified and the output more readable
2023-10-28 09:14:38 +02:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_phase__act
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___eval_triggers_vec__act
Dynamic triggers for non-static contexts (#3599) In non-static contexts like class objects or stack frames, the use of global trigger evaluation is not feasible. The concept of dynamic triggers allows for trigger evaluation in such cases. These triggers are simply local variables, and coroutines are themselves responsible for evaluating them. They await the global dynamic trigger scheduler object, which is responsible for resuming them during the trigger evaluation step in the 'act' eval region. Once the trigger is set, they await the dynamic trigger scheduler once again, and then get resumed during the resumption step in the 'act' eval region. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-10-22 16:05:39 +02:00
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
Fix event triggering (#6932)
2026-02-11 19:35:59 +01:00
-V{t#,#}+ Vt_timing_debug2___024root___timing_ready
-V{t#,#}+ Vt_timing_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___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_debug2___024root___eval_final
Optimize away calls to empty functions (#6626)
2025-11-02 22:11:02 +01:00
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass::~
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass::~
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::~
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::~
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::~