electronic_eel has quit [Ping timeout: 258 seconds]
electronic_eel has joined #nmigen
tannewt has quit [*.net *.split]
guan has quit [*.net *.split]
tpw_rules has quit [Ping timeout: 246 seconds]
tpw_rules has joined #nmigen
guan has joined #nmigen
tannewt has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
saganman has joined #nmigen
saganman has left #nmigen ["WeeChat 1.6"]
chipmuenk has joined #nmigen
lethalbit has quit [Ping timeout: 256 seconds]
lethalbit has joined #nmigen
hitomi2509 has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
Sarayan has joined #nmigen
lethalbit has quit [Ping timeout: 240 seconds]
lethalbit has joined #nmigen
bmartin427 has quit [Ping timeout: 245 seconds]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Ping timeout: 258 seconds]
Asu has joined #nmigen
emeb has joined #nmigen
lethalbit has quit [Ping timeout: 240 seconds]
tannewt has quit [*.net *.split]
guan has quit [*.net *.split]
guan has joined #nmigen
tannewt has joined #nmigen
Qyriad has joined #nmigen
lethalbit has joined #nmigen
tannewt has joined #nmigen
guan has joined #nmigen
Qyriad has quit [Ping timeout: 244 seconds]
guan has quit [Ping timeout: 244 seconds]
tannewt has quit [Ping timeout: 244 seconds]
hitomi2509 has quit [Quit: Nettalk6 - www.ntalk.de]
<agg>
is there a way to get the current timestep from a Simulator? ideally in clock cycles, but nanoseconds would work
DaKnig has quit [Quit: WeeChat 2.9]
DaKnig has joined #nmigen
DaKnig has joined #nmigen
DaKnig has quit [Changing host]
<whitequark>
timestep?
<agg>
I think what I want is simulator._engine.now when using pysim
<agg>
but basically I want to know how many times yield has been called
<agg>
(without otherwise keeping track of it myself, since i'm using a bunch of subgenerators etc)
<whitequark>
ah, there's an open issue
<whitequark>
you could also do it in a different way, launch a concurrent process that does nothing but counts yield
<whitequark>
and use a nonlocal
<agg>
that would work, thanks! missed the existing issue
<whitequark>
i would somewhat prefer the approach with the concurrent process
<whitequark>
since it doesn't depend on the clock generator in any way, and its semantics is exactly what you actually want
<agg>
when you say concurrent process, are you thinking of another call to add_sync_process, or a wrapper around my testbench?
<whitequark>
honestly, either would work. i think a wrapper might be slightly cleaner in a few ways
<whitequark>
we could probably recommend the wrapper in docs at some point
<agg>
hmm, I was expecting `def wrapper(): for tick in testbench(): yield tick` to transparently wrap the testbench, but no joy
<agg>
(I think when the testbench tries to yield from the simulator it doesn't go through; using `yield from testbench()` in the wrapper works but then I can't count the ticks
<whitequark>
hmm
<whitequark>
i think you have to call the testbench with the result of `yield tick`
<agg>
hmm, `def wrapper(): tb = testbench(); for tick in tb: tb.send((yield tick))` seems closer
<agg>
but my tests fail
<whitequark>
drop the for
<whitequark>
result = None; while True: result = tb.send((yield result))
<whitequark>
something like this, i think
<agg>
that seems to work
<agg>
(plus catching the StopIteration etc)
<agg>
guess the for loop was double-pumping the tb
<agg>
need to be a bit cleverer to count clock ticks though
<agg>
if result is None that's a tick, but the tb could also yield Tick etc, right?
<agg>
as it stands it seems to count both the `yield` and the `data = (yield from module.data)` yields
<whitequark>
yes and yes
<whitequark>
the interface kinda sucks
<agg>
conveniently I don't understand the clock stuff and just use `yield` to advance whole cycles, so i can count those very easily and it now all works
<whitequark>
yes, that should be fine for most purposes
<whitequark>
you're not *really* supposed to yield with an argument from sync processes
<lkcl>
whitequark: is this for simulation? we use that trick to create multiple processes which are slightly different
<lkcl>
rather than be forced to have add_sync_process(dut.test_rcv1)
<lkcl>
add.... test_rcv2
<lkcl>
add.... test_rcv3
<lkcl>
etc. etc.
<lkcl>
for i in range(4): add_sync_process(dut.test_rcv(i))
<lkcl>
then we can alter the number of simulation processes depending on the number of Pipeline Reservation Stations to be tested.
<lkcl>
it sounds, "oh yeah that's dumb, of course if you can test with 4 you can test with 5,6,7 or 8, why bother?"
<lkcl>
to which the answer is: the "mask" for the ReservationStations could have been accidentally set up incorrectly, especially with a non-power-of-2 number of Reservation Stations
<lkcl>
and if the mask (destination) is wrong (2 bits for a destination ID between 0 and 6 for example) that's a bug
<whitequark>
uh, i don't think it's dumb
FL4SHK has quit [Read error: Connection reset by peer]
FL4SHK has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
FL4SHK has quit [Quit: rebooting]
FL4SHK has joined #nmigen
emeb_mac has joined #nmigen
FFY00 has quit [Remote host closed the connection]