Add TrueSettle #552
Add TrueSettle #552
Conversation
| def run(self) -> bool: | ||
| deadline = self.deadline * 1e12 | ||
| assert self._engine.now <= deadline | ||
| last_now = self._engine.now | ||
| while self.advance() and self._engine.now < deadline: | ||
| if last_now == self._engine.now: | ||
| if self._check_true_settle_ready(): | ||
| self._unblock_sync_processes() | ||
| last_now = self._engine.now |
There was a problem hiding this comment.
It's unfortunate that you had to dig into Amaranth's internals this much. But still, this gives us the functionality we need.
| def true_settle_process(self): | ||
| for k in range(self.test_cycles): | ||
| yield TrueSettle() | ||
| self.assertTrue(self.flag) | ||
| self.flag = False | ||
| yield | ||
|
|
||
| def flag_process(self): | ||
| for k in range(self.test_cycles): | ||
| for i in range(random.randrange(0, 5)): | ||
| yield Settle() | ||
| self.flag = True | ||
| yield |
There was a problem hiding this comment.
Aren't these kinds of tests prone to race condition?
|
FYI, the upcoming async testbench RFC will interact with this implementation. (It's not entirely clear to me whether it'll block it, or eliminate the need for it; I'd have to dig deeper into how exactly this works.) |
|
@lekcyjna123 Can you tell me more about the issue that triggered the need for |
In some cases we would like to wait with some action till the read-only phase where all signals have been already modified and have stabilized, but before the next clock cycle. One of examples is #547 where we would like to record signal value on the end of clock cycle to generate methods usage profiles. Currently we use either: coreblocks/test/common/profiler.py Line 42 in 7c68414 or but both are some kinds of workaround. First use the fact that we know how long is our cycle and second use the fact that we don't do any operations on negative clock edge.
But now, when I think after some time about my changes, I am not sure if our whole testing idea isn't wrong. Because we entangle two points: operations on circuit signals and imperative operations on python structures. There shouldn't be any need to wait more than one
I haven't checked this new functionality yet. I am going to do that today afternoon. |
This was my concern, but I wanted to understand more about the use case before bringing it up.
Yes. In fact, you can drive a clock domain from a process. Does this work with |
In #547 there is a point:
coreblocks/test/common/profiler.py
Line 37 in 757fcd5
I have decided to implement a draft of such operator, but I have some doubts about the semantic. Should we allow changes in testbench signal inputs after issuing TrueSettle? From one side I can imaginate that we can want to do after all process are in steady state, but this can cause the next round of changes in signal values. So now I think that after TrueSettle no changes in input signals should be allowed.