peepsalot has quit [Read error: Connection reset by peer]
peepsalot has joined #nmigen
shaiku|2 has quit [Read error: Connection reset by peer]
Degi_ has joined #nmigen
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #nmigen
toshywoshy has quit [Read error: Connection reset by peer]
toshywoshy has joined #nmigen
andresmanelli has joined #nmigen
DeVosReynaerde has joined #nmigen
kaucasus has joined #nmigen
<DeVosReynaerde>
I currently have a problem with the timing requirements in my project. Is there a way to write to a nMigen memory module in the same clock cycle as the data is generated, or is the write port bound to be used in the sync domain?
<tpw_rules>
you can combinatorially assign to the write port i believe
<whitequark>
async write ports are not supported
<whitequark>
it's a Yosys limitation, technically, but even if we fixed that, you still own't be able to synthesize it
<mwk>
oh, not really
<mwk>
yosys can represent async write ports
<mwk>
there's no target that actually can do anything with them, but they should work fine if all you do is write_verilog
<mwk>
... they are not actually supported by any modern FPGA, but oh well
<whitequark>
wait, is that new?
<mwk>
nope
<whitequark>
i distinctly remember async write ports not being supported in write_verilog
<mwk>
but I think I fixed some bugs in it when I basically rewrote that part of write_verilog
<whitequark>
huh
<whitequark>
misremembering, then
<mwk>
(the old code was so broken I wasn't really looking at it, though)
<DeVosReynaerde>
Guess I will have to find a workaround then ... Thanks anyway for the help!
<mwk>
DeVosReynaerde: would a sync write port + a bypass path fulfill your needs?
<DeVosReynaerde>
That could indeed be a nice solution, I will try it!
<tpw_rules>
i must be misunderstanding something then. i thought it was async read ports that weren't supported
<mwk>
async read ports are perfectly fine
<mwk>
and supported by LUT RAM on most FPGA targets
<tpw_rules>
wuh? i thought that's why read_port had transparent=False. you get the data the cycle after you set the address
<whitequark>
that's a default parameter
<mwk>
transparency is a term that only makes sense for sync read ports in the first place
<tpw_rules>
maybe i don't understand what is meant by sync and async
<mwk>
whitequark: just checked, async write port correctly roundtrips through read_verilog and write_verilog on current yosys, though it requires explicit (* nomem2reg *) on read_verilog side to not be splatted into lots of latches
<tpw_rules>
i guess as in you have to wait for the clock for the write to happen?
<whitequark>
mwk: thanks
<whitequark>
nmigen needs to be fixed then
<mwk>
... are there even any supported platforms that can do an async write?
<whitequark>
no
<whitequark>
you can do it on ASICs i think?
<mwk>
hmmm
<mwk>
there are very old Xilinx FPGAs that can do it
<whitequark>
and of course you can simulate it
<mwk>
but I don't think my platform code supports them
<whitequark>
it could be useful in some behavioral models, perhaps
<tpw_rules>
DeVosReynaerde: out of curiosity, what do you mean by "bound to be used in the sync domain"?
<mwk>
tpw_rules: sync write port is one that writes on clock edges; async write port has no concept of clock and writes continuously whenever the write enable is asserted
<mwk>
async write ports are generally mostly extinct
<tpw_rules>
mwk: okay yeah. then i don't think i interpreted the initial question the same way you did.
<mwk>
similarly, sync read port is one that reads on clock edges and async read port is one that reads continuously
<mwk>
and transparency is really a property of a *pair* of read+write ports
<mwk>
when a read and a write happen at the same clock edge to the same address, transparency says what happens
<mwk>
non-transparent: you get the previous value, transparent: you get the new value
<whitequark>
side note: a lot of weird things around transparency boil down to what "same clock edge" actually means
<mwk>
(these are not the only two options, there are plenty of FPGAs where the behavior is actually "undefined")
<whitequark>
because clocking is rarely semantically explicit in HDLs and so a lot of tools have to guess one way or another
<whitequark>
simulators too
<mwk>
transparency is well defined when the clocks on the two ports are actually the same; when they are different it's... yosys doesn't even attempt to support this, using the "previous value" semantics in this case by default
<mwk>
(it's actually possible to well-define it as well, but not to express it nicely in Verilog or lower to plain FFs if native mapping is not available, so it's a major pain in practice to support this)
andresmanelli has quit []
<DeVosReynaerde>
mwk: Bypassing resolved my negative slack, thank you very much
DeVosReynaerde has quit [Quit: Client closed]
emeb has joined #nmigen
kaucasus has quit [Quit: Client closed]
<_whitenotifier-1>
[nmigen] hansfbaier opened issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP7go
<_whitenotifier-1>
[nmigen] rroohhh commented on issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP726
<_whitenotifier-1>
[nmigen] rroohhh edited a comment on issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP726
<_whitenotifier-1>
[nmigen] hansfbaier commented on issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP7aO
<_whitenotifier-1>
[nmigen] hansfbaier closed issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP7go
<_whitenotifier-1>
[nmigen] hansfbaier edited a comment on issue #645: VCDWriter.register_alias() called in pysim.py:110 does not exist - https://git.io/JP7aO