<daveshah>
That one always reflects the last release
<daveshah>
I think if you want one for master then you will need to build it yourself
<lambda>
according to github 0.9 was released in august 2019, the manual download is from october 2018 (both according to Last-Modified header and contents)
<daveshah>
oh right, must be from 0.8 then
<lambda>
I just finished building it myself, no worries
tlwoerner has joined #yosys
X-Scale has joined #yosys
TFKyle has joined #yosys
jfcaron has joined #yosys
citypw has quit [Remote host closed the connection]
philtor has quit [Ping timeout: 246 seconds]
dys has joined #yosys
thehardway is now known as bwidawsk
dys has quit [Ping timeout: 244 seconds]
jeanthom has quit [Ping timeout: 240 seconds]
jakobwenzel has quit [Remote host closed the connection]
<whitequark>
the most important issue with this plan is that it restricts transparency to exactly one memrdwr port
<whitequark>
there's no technical reason for that. if you have one write and two read ports in the same domain, which is in fact common (a register file is that!) then you can have both read ports transparent
<whitequark>
if the hardware doesn't support it, yosys can insert transparency logic on its own.
<whitequark>
also, tying transparency to memrdwr ports makes inference a lot harder
<whitequark>
it has to be a frontend decision because there is no way for a frontend to encode that a memrd+memwr pair should have transparency enabled
<whitequark>
it also makes it harder to combine ports
<mwk>
... tbh it kind of matches xilinx hardware, at least
<whitequark>
yeah which is why i'm pushing against it
<whitequark>
let's not privilege a single vendor
<mwk>
yes
<mwk>
we should probably go through a good amount of vendors' mem primitives and catalogue their capabilities
<mwk>
then figure out how to deal with all that
<mwk>
transparancy being likely the messiest part
<whitequark>
i did that, sorta
<whitequark>
or rather i asked people to do that
<daveshah>
Lattice are noticeably poor at documenting their transparency behaviour
<tpb>
Title: Implement a sanitizer for memory port combinations · Issue #14 · nmigen/nmigen · GitHub (at github.com)
<lambda>
whitequark: alright, how can we model transparency between arbitrary sets of $memrd and $memwr then? afaict it should be possible to be transparent to one write port, but not another
<mwk>
transparency is only a thing within one clock domain, right?
<whitequark>
yes
<daveshah>
not convinced myself
<daveshah>
I think you can have multi clock transparency too
<whitequark>
hm
<whitequark>
sure
<mwk>
hmm, right, transparency would be a thing between 1× and 2× clock
<mwk>
etc
<whitequark>
let's have transparency groups
<daveshah>
one way to consider transparency is moving the register to the address rather than the data output
<lambda>
daveshah: isn't that mostly undefined behaviour in actual hardware?
<daveshah>
for BRAM, probably
<mwk>
daveshah: no, that's bullshit
<mwk>
and aaargh
<whitequark>
that interacts badly with read enables
<mwk>
yosys has that pattern everywhere
<mwk>
yes
<whitequark>
and is one thing i would like to explicitly get rid of
<mwk>
having register on address is actually an *async* read port
<whitequark>
nmigen actually currently has RE of transparent ports hardwired to 1
<mwk>
it's a giant sim-synth mismatch
<mwk>
let's kill it with fire
<daveshah>
that will break migen
<daveshah>
but maybe that doesn't matter
<mwk>
and as for transparency with multi clocks
<mwk>
how would that even be described in HDL?
<lambda>
whitequark: transparency groups sound promising, would they just be metadata in RTLIL::Memory?
<mwk>
or how could yosys insert transparency logic in this case
<daveshah>
I removed the transparency logic creation for multiple clocks because it was so obviously broken
<daveshah>
Yosys used to attempt to create it but it just made things much worse
<mwk>
in xilinx, AFAIUI, transparency is an attribute of the *write* port, accomplished by moving its write strobe early (before the read strobe)
<daveshah>
yes, ECP5 is identical
<mwk>
so it's implementable on that particular hardware
<daveshah>
even has the same three settings
<mwk>
but if it gets to soft logic, aren't we screwed?
<daveshah>
yep
jfcaron has quit [Ping timeout: 260 seconds]
<lambda>
does anything actually use cross-clock transparency? maybe we should just find a design that can easily be expanded to accommodate it later (like transparency groups) and then forget about it
kraiskil_ has joined #yosys
<whitequark>
transparency groups would not be metadata in RTLIL::Memory
<whitequark>
they should probably be a parameter on memory ports
<whitequark>
another thing you're missing is the NO_CHANGE behavior of a $memwr port
<whitequark>
i.e. read xor write
<mwk>
that's kind of implied in the READ_EN and WRITE_EN signals
<lambda>
whitequark: yeah, I was gonna ask that, what exactly is that mode? can't say I've come across it before
<mwk>
which are... kind of problematic
<mwk>
because eg. xilinx doesn't support them separately
<mwk>
basically xilinx has two settings: WRITE_EN either always implies READ_EN, or always implies !READ_EN
<whitequark>
oh wtf
<mwk>
the latter is called the NO_CHANGE mode
<mwk>
hmm wait
emeb_mac has joined #yosys
<mwk>
alright
<mwk>
so how it works on xilinx: you have a single-bit EN input, and multi-bit WE input (write enable per byte)
<mwk>
... at least according to sim model, it's not exactly spelled out in the user guide
<lambda>
should that pattern be part of the mem cells, or should BRAM inference check if READ_EN == WRITE_EN (or READ_EN == (not WRITE_EN) respectively)?
<mwk>
oh it's more complex than the latter
<mwk>
what it should check is whether WRITE_EN *implies* READ_EN or !READ_EN
<mwk>
since it's perfectly acceptable for both to be 0
<mwk>
(by turning off EN)
<mwk>
also note that WE is a multi-bit signal
<mwk>
so actually it's
<mwk>
so actually it's |WRITE_EN implies READ_EN / !READ_EN
<mwk>
and well, it should be part of BRAM inference check, I guess?
<mwk>
because you can have a target where that just doesn't matter
<mwk>
however, there's a more interesting question here
<mwk>
how should the memory inference pass be structured?
<mwk>
it may or may not be a single monolithical pass
<mwk>
clearly we're going to need some sort of "configuration file" for this pass, like the current one
<whitequark>
what is a 'memory inference pass'?
<mwk>
also it's clear that this pass will need to be run on wildly different configurations in the same synth flow (lut ram vs bram vs ultraram)
<whitequark>
just the replacement for memory_bram?
<mwk>
whitequark: the not-yet-designed pass that turns generic cells into ones matching target capabilities
<mwk>
yeah, memory_bram 2.0
<whitequark>
yeah makes sense
<whitequark>
at the very least i request a separate pass for checking $meminit cells
<mwk>
anyway: the existence of both bram and lutram in the same fpga implies that matching this xilinx enable pattern needs to be depend on the final ram type used, so cannot be done by looking at the port in isolation
<mwk>
yeah, that doesn't ave to be the only pass
<mwk>
I'd imagine we'd still have some minor memory_* passes that run first, like memory_opt
<mwk>
(which would probably now have the task of detecting common asymmetric memory patterns and gluing ports together?)
<lambda>
alright, so are transparency groups the only thing that needs to change in the cell design? NO_CHANGE could either be implemented as a $memrdwr parameter, or be inferred during BRAM mapping
<whitequark>
so far i think it is
<whitequark>
once everyone agrees with the general design there's gonna be bikeshedding of the names, too
<whitequark>
but not yet
<lambda>
oh sure, I've always expected that to happen, I chose descriptive names for now