<whitequark>
you can do yield x.eq(y); yield z.eq(t), which is basically the same as having multiple assignments
<whitequark>
since the timeline doesn't advance unless you yield or yield Settle()
<DevanshTanna[m]>
Ohh okay, I thought one yield takes one clock cycle, Thanks for the help
balrog has quit [Quit: Bye]
balrog has joined #amaranth-lang
DevanshTanna[m] is now known as DeVector[m]
<josuah>
> since the timeline doesn't advance unless you yield or yield Settle()
<josuah>
I was not sure, but that puts an end to my doubts... nice!
<josuah>
such a great way to perform simulation!
<whitequark>
it's actually a fairly difficult to use interface; there are plans to replace it with something less error-prone
<whitequark>
the difficulty is in the following. suppose you change a signal from 0 to 1. when do other signals connected to it change?
<whitequark>
right now the answer is "after `yield` or `yield Settle()`" and because of that sometimes when writing a testbench you sprinkle `yield` all over it until it works. not a great design
<josuah>
so you mean it becomes a bit too verbose when debugging combinational signals?
<whitequark>
it's more that it's difficult to think about
<whitequark>
there's going to be an RFC describing the issues in more detail some time later this quarter
<josuah>
very glad to see development taking this pace
<josuah>
not rushing into anything yet addressing everything
<josuah>
that kinds of break the "move fast break things (sucessor would clean)"