electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
<whitequark>
awygle: just woke up
<whitequark>
mithro: interesting!
<awygle>
whitequark: i'm still here, if you want to discuss things at whatever point
<whitequark>
awygle: yup, let me grab something to eat
<whitequark>
awygle: alright, so this time, i'd like to talk about memories
<whitequark>
you probably remember how wires work: there's `curr` and `next`, all updates go to `next`, then they get atomically committed to `curr`
<whitequark>
which avoids races between different processes
<awygle>
MHM
<awygle>
...mhm
<whitequark>
for memories, this doesn't really work as-is because commit would be O(n)
<whitequark>
(used to be implemented that way)
<whitequark>
so instead, i have an array of the values in the memory acting as `curr`, and a queue acting as `next`
<awygle>
mk
<whitequark>
basically, i record the new value, its mask (necessary because of fine grained write enables), its priority (necessary because yosys has write port priority) and commit that queue
<whitequark>
makes sense so far?
justlooking has joined #nmigen
<awygle>
"commit that queue" meaning "at the point where signals are atomically committed, process all commands in the queue"?
<whitequark>
yep
<awygle>
then yes
justlooking has quit [Remote host closed the connection]
<whitequark>
the problem is: the C API doesn't expose anything to add items to the queue, and it'd be somewhat hard to do so
<whitequark>
because the queue is an std::vector and a cxxrtl_object has no way of going back to cxxrtl::memory and even if you did you can't manipulate the vector without un-erasing the templated type inside and o on
<whitequark>
*so on
<whitequark>
it *is* possible to implement, but it would take significant development time and incur nontrivial overhead in compilation time and runtime space
<awygle>
mm, yeah
<whitequark>
what i'm trying to figure out is: in what circumstances would this API come useful?
<whitequark>
note that one thing it will *not* be able to handle (and there isn't a world where it will handle that) is transparent memories
<whitequark>
so if you have a testbench read and write 'ports' and the read must be transparent, you have to manually bypass
<whitequark>
if you have a testbench read 'port' and an RTL write port you also have to manually bypass (and it's even more annoying)
<whitequark>
so i can think of two low-level situations where it would be useful:
<whitequark>
- write-after-write hazard, where two testbenches (or testbench and RTL) write to the same memory address and the result must be predictable
<whitequark>
- read-after-write hazard, which is basically the same thing but it's the read value that must be predictable
<awygle>
makes sense
<awygle>
"somebody pokes an address, somebody else tries to do something with that address, without a clock sequence point in between"
<whitequark>
essentially
<whitequark>
the most common use for memory r/w in testbenches is, of course, initializing ROMs, and extracting computed data
<whitequark>
all of which can be done while the design is held in rese
<whitequark>
*reset
<whitequark>
but... are there other uses that i must support?
<awygle>
i can't really think of other reasons to have one port in the TB and one port in the DUT
<awygle>
even that feels kind of gross to me tbh
<whitequark>
ok, so i conclude i can safely skip making that pattern race-free, given the amount of effort it would require
<awygle>
that is what we're talking about here, right? only the case where the ports span the TB/DUT boundary?
<whitequark>
you could also have both ports in TB
<awygle>
if so then i agree, document and move on
<whitequark>
when two ports are both in DUT, this *is* handled as you would expect from a HDL
<awygle>
right
<awygle>
and if both ports are in the TB, the user has full control over the sequencing, right? because they can always yield or settle or whatever they need
<whitequark>
soooort of
<whitequark>
actually writing code that would reliably sequence two independent TB accessing one memory is not trivial
<whitequark>
but yes, there are enough knobs to do so
<awygle>
right
<whitequark>
you probably want to have some sort of fully asynchronous stb/ack logic
<awygle>
anything you do in this space is going to have an inherent pain-in-the-ass-ness
<awygle>
but that's not a bad thing tbh, it should serve as a warning to _really_ think about whether you need to be doing it
<whitequark>
arguably so, yeah
<awygle>
it's moving on towards bedtime, anything else you want to discuss today?
<whitequark>
that's all; there's more i'd like to discuss, but i have my work cut out for me today
<whitequark>
so, maybe tomorrow
<awygle>
mk, sounds good
emeb_mac has quit [Quit: Leaving.]
chipmuenk has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
lkcl has quit [Ping timeout: 246 seconds]
lkcl has joined #nmigen
jeanthom has joined #nmigen
nelgau has quit [Remote host closed the connection]
<_whitenotifier>
[nmigen] whitequark commented on issue #556: cxxsim: simulator-only signals not included in VCD and GTKWave files - https://git.io/JIRhx
<_whitenotifier>
[nmigen] cestrauss opened issue #557: cxxsim: Python process can't override combinatorial assignment - https://git.io/JIRjV
<_whitenotifier>
[nmigen] cestrauss commented on issue #556: cxxsim: simulator-only signals not included in VCD and GTKWave files - https://git.io/JI0ee
jeanthom has quit [Ping timeout: 256 seconds]
<_whitenotifier>
[nmigen] whitequark commented on issue #557: cxxsim: Python process can't override combinatorial assignment - https://git.io/JI0es
<_whitenotifier>
[nmigen] whitequark commented on issue #556: cxxsim: simulator-only signals not included in VCD and GTKWave files - https://git.io/JI0e4
<_whitenotifier>
[nmigen] whitequark edited issue #557: pysim: Python testbenches should not be able to assign combinatorially driven signals - https://git.io/JIRjV
<_whitenotifier>
[nmigen] whitequark edited issue #557: Python testbenches should not be able to assign combinatorially driven signals - https://git.io/JIRjV
<_whitenotifier>
[nmigen] whitequark commented on issue #557: Python testbenches should not be able to assign combinatorially driven signals - https://git.io/JI0e6
<_whitenotifier>
[nmigen] whitequark edited a comment on issue #557: Python testbenches should not be able to assign combinatorially driven signals - https://git.io/JI0es
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 240 seconds]
jeanthom has joined #nmigen
wisnaut has quit [Remote host closed the connection]