Conversation
|
schilkp/circumspect@3988437 fixes the previous problem we had. |
| end | ||
|
|
||
| // Fetch enable | ||
| if (fetch_en_asserted) begin |
There was a problem hiding this comment.
Just FYI:
slice_set(), as opposed to slice_begin(), will check if a slice is already active on the given track, and if so end it before starting a new one.
If the .compress(1) option is set, slice_set will additionally check if the slice message it was given matches the message of the already active slice, in which case it will do nothing.
slice_end() will check if a slice is actually active, and otherwise do nothing.
All of this together means you don't need the rising/falling edge detector, and you can simply, on every clock edge call slice_set(.compress(1)...) if a given condition is active, or slice_end() if not.
I implemented it this way for this exact use case, because it is super common. Maybe the function naming is bad?
The lack of documentation is certainly not helping 😇
There was a problem hiding this comment.
Ahhh makes sense actually, I was not sure whether it was intended that way and whether adding many unnecessary DPI calls every cycle would have caused slowdowns, but honestly I did not really explore that. Thanks!! :)
More tips are always welcome 😉
There was a problem hiding this comment.
I did consider the slowdown issue - there is a world where moving this logic across the DPI boundary to the SV package would be beneficial. But that would have to be profiled and be rather simulator-specific I guess :)
3 participants
This PR adds support for CircumSpect, an open-source RTL DPI tracing library developed in Rust. When enabled, CircumSpect generates custom protobuf trace logs which can be analyzed via the Perfetto trace viewer on a web browser.
This PR provides a simple CircumSpect setup which logs the main components / interfaces of the CVE2 core. It is meant as a basic example providing a quick overview of the core's state during RTL simulation, which can be extended depending on each project needs.
Although the protobuf binary format is rather compact, care should be taken in the amount of state needed, especially for long simulations, as the trace log file size can become quite large. In the current setting, when enabled a ~50MB trace file is generated when running the helloworld test on Croc.
NOTE: adds cargo to the tooling requirements.