VPI dirtiness tracking #5065
VPI dirtiness tracking #5065
Conversation
There was a problem hiding this comment.
This seems to have a "secret handshake" with cocotb.
Is there any IEEE-specified VPI call that should be used instead?
Probably not, so, please add "///" comments to the functions describing how to be used, and also document in some appropriate point in the main user guide.
include/verilated_vpi.cpp
Outdated
| @@ -2441,6 +2447,7 @@ vpiHandle vpi_put_value(vpiHandle object, p_vpi_value valuep, p_vpi_time /*time_ | |||
| return nullptr; | |||
| } | |||
| if (const VerilatedVpioVar* const vop = VerilatedVpioVar::castp(object)) { | |||
| VerilatedVpiImp::setDirty(true); | |||
There was a problem hiding this comment.
Please move after first debug print.
Mostly. However, other VPI users could make use of it too.
I don't see anything. And I believe that makes sense since the eval-or-not decision isn't really available with other simulators. |
|
P.S. if this is all in cocotb, why can't it track the bool itself? |
Yeah, I was thinking about that too. I guess I'm paranoid that someone will use the VPI w/o going through cocotb and then it won't know that the DUT has been touched. AKA, the only component in this system that can truly know if the DUT has been disturbed via the VPI is |
|
I suppose cocotb could be usedin addition to other vpi/dpi extensions. Please update docs, then I'll take this. |
include/verilated_vpi.cpp
Outdated
| static void setDirty(bool dirty) { s().m_dirty = dirty; } | ||
| static bool isDirty() { return s().m_dirty; } |
There was a problem hiding this comment.
| static void setDirty(bool dirty) { s().m_dirty = dirty; } | |
| static bool isDirty() { return s().m_dirty; } | |
| static void setDirty(bool dirty) { s().m_dirty = dirty; } | |
| static bool dirty() { return s().m_dirty; } |
Accessors don't usually have "is". Though occasionally break that rule.
I wonder if vpiEvalNeeded would be more descriptive than ditry?
There was a problem hiding this comment.
I wonder if vpiEvalNeeded would be more descriptive than ditry?
I can go that way, however should it just be evalNeeded() since this is already in the VerilatedVpiImp class? Also, I'd then think we'd want to s/clearDirty/clearEvalNeeded and s/setDirty/setEvalNeeded. How's that sound?
docs/guide/connecting.rst
Outdated
| a "dirty" flag. This flag can be checked with :code:`VerilatedVpi::isDirty()` | ||
| and it can be cleared with :code:`VerilatedVpi::clearDirty()`. Used together |
There was a problem hiding this comment.
Function names need updating.
include/verilated_vpi.cpp
Outdated
| @@ -813,6 +814,8 @@ class VerilatedVpiImp final { | |||
| } | |||
| static void dumpCbs() VL_MT_UNSAFE_ONE; | |||
| static VerilatedVpiError* error_info() VL_MT_UNSAFE_ONE; // getter for vpi error info | |||
| static void setEvalNeeded(bool evalNeeded) { s().m_evalNeeded = evalNeeded; } | |||
There was a problem hiding this comment.
| static void setEvalNeeded(bool evalNeeded) { s().m_evalNeeded = evalNeeded; } | |
| static void evalNeeded(bool evalNeeded) { s().m_evalNeeded = evalNeeded; } |
For cocotb or any other VPI users. Can be used to skip evals if callbacks happen which don't use
vpi_put_value(). We've gotten decent performance gains with this. I'll post the cocotb side separately.