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

1564 lines
102 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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2___024unit___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___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass__Vclpkg___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__Vclpkg___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__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkDelayClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aLocalWaitClass__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay__Vclpkg___ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass__Vclpkg___ctor_var_reset
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as 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#,#}+ 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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::new
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::_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__03aEventClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::_ctor_var_reset
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::new
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::_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__03aWaitClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aWaitClass::_ctor_var_reset
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::new
-V{t#,#}+ Vt_timing_debug2___024unit__03a__03aBaseClass::_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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_initial
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__0
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#,#} Suspending process waiting for @([event] t.ec.e) at t/t_timing_class.v:111
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__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
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_count_5
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:97
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__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__03aDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay10::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay20::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelay40::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aDelayClass::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aNoDelay::_ctor_var_reset
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aAssignDelayClass::_ctor_var_reset
-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::_ctor_var_reset
-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
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#,#} Awaiting join of fork at: t/t_timing_class.v:250
-V{t#,#} Awaiting join of fork at: t/t_timing_class.v:245
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:97
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:97
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:97
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
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#,#} Committing 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#,#} - Process waiting at t/t_timing_class.v:111
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:97
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:97
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:97
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 5: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:173
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:247
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:119
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#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:252
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
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#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
-V{t#,#} Resuming delayed processes
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:97
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:97
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:97 awaiting resumption
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Resuming processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:97
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:97
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
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#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:173
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:247
-V{t#,#} Awaiting time 10: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:119
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:252
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
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#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:173
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
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:247
-V{t#,#} Process forked at t/t_timing_class.v:246 finished
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
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 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___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
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 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___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 15: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:119
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:252
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:174
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:98 awaiting resumption
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Resuming processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:98
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:98
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
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#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:119
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:252
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 20: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:174
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:119
-V{t#,#}+ Vt_timing_debug2_t__03a__03aEventClass::__VnoInFunc_wake
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:252
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__03aForkDelayClass::new
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkDelayClass::_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#,#} Process forked at t/t_timing_class.v:251 finished
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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)
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
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#,#} Ready 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#,#} - Process waiting at t/t_timing_class.v:111
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)
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: Process waiting at t/t_timing_class.v:111
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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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 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:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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())
-V{t#,#} Doing post updates for processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 25: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:174
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:99 awaiting resumption
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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())
-V{t#,#} Doing post updates for processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Resuming processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:99
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:99
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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:
-V{t#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
-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 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:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
-V{t#,#} Doing post updates for processes:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:257
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:174
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 30: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:257
-V{t#,#}+ Vt_timing_debug2_t__03a__03aForkDelayClass::__VnoInFunc_do_delay
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:174
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
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: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
-V{t#,#} Doing post updates for processes:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 35: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
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#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
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: Process waiting at t/t_timing_class.v:100
-V{t#,#} Process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:100 awaiting resumption
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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())
-V{t#,#} Doing post updates for processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Resuming processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:100
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:100
-V{t#,#} Suspending process waiting for @(posedge t::ClkClass.clk) at t/t_timing_class.v:101
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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
-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 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:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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 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:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
-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())
-V{t#,#} Doing post updates for processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Suspending process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:120
-V{t#,#} Awaiting time 40: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:120
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: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-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 marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting the post update step
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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 dynamic triggers for named events (#4571)
2023-10-16 17:06:41 +02:00
-V{t#,#} 'act' region trigger index 2 is active: @([true] __VdynSched.evaluate())
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
-V{t#,#} Process waiting for @([event] t::EventClass.e) at t/t_timing_class.v:37 awaiting resumption
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
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 ready processes waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes waiting for @([event] t.ec.e)
-V{t#,#} Resuming processes:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:37
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:37
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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
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: 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 marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
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#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 45: Process waiting at t/t_timing_class.v:131
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#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Resuming processes:
-V{t#,#} - Process waiting at t/t_timing_class.v:101
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:101
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
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#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:122
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 50: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:122
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: Process waiting at t/t_timing_class.v:131
-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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 55: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 60: 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#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix 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: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Suspending process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_class.v:123
-V{t#,#} Awaiting time 60: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:123
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: Process waiting at t/t_timing_class.v:131
-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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
-V{t#,#} Process waiting for @([true] ((32'sh4 == t::WaitClass.a) & (32'sh10 < t::WaitClass.b))) at t/t_timing_class.v:58 awaiting resumption
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:58
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:58
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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
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
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} Awaiting join of fork at: t/t_timing_class.v:74
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 65: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:76
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} Suspended processes waiting for dynamic trigger evaluation:
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Suspending process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:238
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:175
-V{t#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:76
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#,#} Awaiting time 70: Process waiting at t/t_timing_class.v:131
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:238
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#,#} Process forked at t/t_timing_class.v:256 finished
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:250
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#,#} Process forked at t/t_timing_class.v:250 finished
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:245
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:175
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
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:76
-V{t#,#} Process forked at t/t_timing_class.v:76 finished
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Process waiting for @([true] ((32'sh2a == t::LocalWaitClass.a) | (32'sh64 != t::LocalWaitClass.b))) at t/t_timing_class.v:75 awaiting resumption
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
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:
Fix marking overridden methods as coroutines (#4120) (#4169) This patch fixes two cases where methods in base classes were not being marked as coroutines, even though they were being overridden by coroutines. - One case is the class member cache not getting refreshed for searched classes. - The other is when the overriding methods are not declared as `virtual`. In that case, the `isVirtual()` getter on such a method returns false, which led to `V3Timing` skipping the step of searching for overridden methods. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2023-05-04 15:27:45 +02:00
-V{t#,#} - Process waiting at t/t_timing_class.v:75
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:75
-V{t#,#} Process forked at t/t_timing_class.v:75 finished
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:74
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 75: Process waiting at t/t_timing_class.v:224
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 75: Process waiting at t/t_timing_class.v:131
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
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#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:190
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:224
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: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:136
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:190
-V{t#,#} Awaiting time 80: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:136
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:190
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
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
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 85: Process waiting at t/t_timing_class.v:230
-V{t#,#} Awaiting time 85: Process waiting at t/t_timing_class.v:131
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#,#} Awaiting time 90: Process waiting at t/t_timing_class.v:190
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:230
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: Process waiting at t/t_timing_class.v:131
-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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 90: Process waiting at t/t_timing_class.v:190
-V{t#,#} Awaiting time 90: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:231
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix 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: Process waiting at t/t_timing_class.v:190
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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())
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 95: Process waiting at t/t_timing_class.v:131
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:231
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
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
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
-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 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_triggers__act
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
-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 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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 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_triggers__act
-V{t#,#} No suspended processes waiting for dynamic trigger evaluation
-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())
-V{t#,#}+ Vt_timing_debug2___024root___timing_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-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
-V{t#,#} Delayed processes:
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:231
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#,#} Awaiting time 100: Process waiting at t/t_timing_class.v:131
Optimize timing-delayed queue (#4584). (#4669)
2023-11-11 16:04:10 +01:00
-V{t#,#} Awaiting time 101: Process waiting at t/t_timing_class.v:274
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals documentation for more details. Signed-off-by: Krzysztof Bieganski <kbieganski@antmicro.com>
2022-08-22 14:26:32 +02:00
-V{t#,#} Resuming delayed processes
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:231
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as 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 *-*
Fix coroutine handle movement during queue manipulation (#4431)
2023-08-21 16:22:09 +02:00
-V{t#,#} Resuming: Process waiting at t/t_timing_class.v:131
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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_triggers__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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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
Timing support (#3363) Adds timing support to Verilator. It makes it possible to use delays, event controls within processes (not just at the start), wait statements, and forks. Building a design with those constructs requires a compiler that supports C++20 coroutines (GCC 10, Clang 5). The basic idea is to have processes and tasks with delays/event controls implemented as C++20 coroutines. This allows us to suspend and resume them at any time. There are five main runtime classes responsible for managing suspended coroutines: * `VlCoroutineHandle`, a wrapper over C++20's `std::coroutine_handle` with move semantics and automatic cleanup. * `VlDelayScheduler`, for coroutines suspended by delays. It resumes them at a proper simulation time. * `VlTriggerScheduler`, for coroutines suspended by event controls. It resumes them if its corresponding trigger was set. * `VlForkSync`, used for syncing `fork..join` and `fork..join_any` blocks. * `VlCoroutine`, the return type of all verilated coroutines. It allows for suspending a stack of coroutines (normally, C++ coroutines are stackless). There is a new visitor in `V3Timing.cpp` which: * scales delays according to the timescale, * simplifies intra-assignment timing controls and net delays into regular timing controls and assignments, * simplifies wait statements into loops with event controls, * marks processes and tasks with timing controls in them as suspendable, * creates delay, trigger scheduler, and fork sync variables, * transforms timing controls and fork joins into C++ awaits There are new functions in `V3SchedTiming.cpp` (used by `V3Sched.cpp`) that integrate static scheduling with timing. This involves providing external domains for variables, so that the necessary combinational logic gets triggered after coroutine resumption, as well as statements that need to be injected into the design eval function to perform this resumption at the correct time. There is also a function that transforms forked processes into separate functions. See the comments in `verilated_timing.h`, `verilated_timing.cpp`, `V3Timing.cpp`, and `V3SchedTiming.cpp`, as well as the internals 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_commit
Internals: Replace VlTriggerVec with unpacked array (#6616) Removed the VlTriggerVec type, and refactored to use an unpacked array of 64-bit words instead. This means the trigger vector and its operations are now the same as for any other unpacked array. The few special functions required for operating on a trigger vector are now generated in V3SchedTrigger as regular 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_orInto__act
-V{t#,#}+ Vt_timing_debug2___024root___trigger_anySet__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__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::~