clifford changed the topic of #yosys to: Yosys Open SYnthesis Suite: http://www.clifford.at/yosys/ -- Channel Logs: https://irclog.whitequark.org/yosys
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
craigo has joined #yosys
<mwk> lambda: not really, I've been... busy with other things
<mwk> so far what I've done is just gathering the requirements in the issue
_whitelogger has joined #yosys
FFY00 has quit [Read error: Connection reset by peer]
FFY00 has joined #yosys
rlee287 has quit [Quit: Konversation terminated!]
Cerpin has quit [Read error: Connection reset by peer]
ktemkin_ has joined #yosys
citypw has joined #yosys
Twix has quit [*.net *.split]
promach3 has quit [*.net *.split]
whitequark has quit [*.net *.split]
Sarayan has quit [*.net *.split]
ktemkin has quit [*.net *.split]
ktemkin_ is now known as ktemkin
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #yosys
jryans has quit [Ping timeout: 260 seconds]
rjo has quit [Ping timeout: 246 seconds]
emily has quit [Ping timeout: 260 seconds]
Cerpin has joined #yosys
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #yosys
promach3 has joined #yosys
emily has joined #yosys
rjo has joined #yosys
jryans has joined #yosys
BinaryLust has quit [Ping timeout: 240 seconds]
BinaryLust has joined #yosys
BinaryLust has quit [Ping timeout: 265 seconds]
az0re has quit [Remote host closed the connection]
kraiskil has joined #yosys
craigo has quit [Ping timeout: 246 seconds]
kgugala_ has joined #yosys
emeb_mac has quit [Quit: Leaving.]
kgugala has quit [Ping timeout: 265 seconds]
kgugala_ has quit [Ping timeout: 240 seconds]
kraiskil has quit [Ping timeout: 256 seconds]
dys has joined #yosys
dys has quit [Ping timeout: 246 seconds]
az0re has joined #yosys
N2TOH_ has joined #yosys
N2TOH has quit [Ping timeout: 246 seconds]
rswarbrick has joined #yosys
<rswarbrick> Just out of interest, is the lack of unique_ptr in the codebase a historical thing, or a style/design decision? As part of adding bind support, I need a couple of new classes, and I'm wondering whether to delete pointers in a destructor, or use smart pointers. I *think* the two options compile to the same thing.
<daveshah> afaik, Yosys was pre-C++11 at one point
<daveshah> unique_ptr should be fine now though, imo anyway
<rswarbrick> Cool, makes sense to me.
Asu has joined #yosys
madushan1000 has joined #yosys
dys has joined #yosys
vidbina has joined #yosys
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
vidbina has quit [Ping timeout: 256 seconds]
rswarbrick has quit [Ping timeout: 256 seconds]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 272 seconds]
jfcaron_ has joined #yosys
jfcaron_ has quit [Read error: Connection reset by peer]
az0re has quit [Ping timeout: 240 seconds]
<lambda> mwk: alright, that's great - won't get very far without any set goals and requirements
emeb has joined #yosys
<ZirconiumX> Good luck, lambda
<lambda> thanks :D still waiting for whitequark to reconnect to discuss her ideas, but I already see this won't be pretty
<ZirconiumX> Start from the very basics and work upward, I suppose :P
<ZirconiumX> Software development in Yosys is driven by people wanting to die on incredibly specific hills
<lambda> well, at least there's passion
<ZirconiumX> I maintain my own synthesis flow that - to my knowledge - nobody but me uses
<ZirconiumX> So
vidbina has joined #yosys
Twix has joined #yosys
craigo has joined #yosys
whitequark has joined #yosys
<ZirconiumX> wb whitequark
X-Scale` has joined #yosys
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
<mithro> Is there a way to create a verilog define which expands to nothing?
<ZirconiumX> Why not just `define THING ?
<lambda> hey whitequark, got some time to philosophise about memory?
<mithro> ZirconiumX: That is what I /thought/ I could do - but it doesn't seem to work
vidbina has quit [Write error: Connection reset by peer]
vidbina has joined #yosys
vidbina has quit [Ping timeout: 264 seconds]
<mithro> Oh, I need to put a ` in front of the macro value
<whitequark> lambda: sure
<whitequark> ZirconiumX: wb?
<lambda> whitequark: I'm trying to start with data structures - as far as I can tell, (RTLIL::Memory + $memrd + $memwr + $meminit) are already capable of representing most of the necessary memory models (maybe with some more transparency options), but $mem *definitely* is not, so we have to stop normalizing to that
<whitequark> do we?
<lambda> I don't think any single cell normalization will work
<whitequark> why?
<whitequark> (i don't know that it will, and i don't know that it won't)
<lambda> how should arbitrarily many arbitrary-width access ports be represented? I guess dynamically creating module ports and parameters would be possible, but I've never seen that with any other cell in yosys, so not sure if that's even sane
citypw has quit [Ping timeout: 240 seconds]
<ZirconiumX> whitequark: welcome back
<ZirconiumX> lambda: I feel like handling "arbitrarily many" is impractical, but also missing the point a little
<lambda> ZirconiumX: well, sure. but even two differently-sized read and write ports each would be a bit of a mess already
<whitequark> i think $mem already has dynamically created module ports and parameters?
<lambda> nope, not according to the manual at least
<whitequark> oh, i see what you mean
<whitequark> hmm
<whitequark> lambda: have you read the discussion here? https://github.com/YosysHQ/yosys/issues/1134
<tpb> Title: Synthesis of asymmetric block RAMs · Issue #1134 · YosysHQ/yosys · GitHub (at github.com)
<lambda> I have not, thanks
<ZirconiumX> lambda: The Cyclone V supports that kind of thing, but as far as I can tell, address lines + data lines is a constant there.
<lambda> whitequark: alright, yeah, I think the $mem.+ cells can stay as is - $mem can either stay as is, and only be able to model symmetric memories, or be expanded/changed for asymmetric memories *somehow*
<whitequark> fwiw i also at first leaned towards killing $mem
<whitequark> but it seems that Claire wants it to stay
<lambda> now, is it easier to hack around with $mem, or to change all consumers of $mem to use the split cells instead?
az0re has joined #yosys
<whitequark> i don't know if the latter will get merged
<lambda> also, for read+write port sharing, a $memport cell with fixed data+address widths, a common clock, one optional read port, and one optional write port would be nice, but adding yet another cell to this mess is probably not gonna happen
<whitequark> i would ask first before spending any time implementing it
<lambda> oh definitely, just trying to come up with designs that just satisfy the requirements at all
<whitequark> ah, yeah
az0re has quit [Remote host closed the connection]
az0re has joined #yosys
rjo has quit [Ping timeout: 240 seconds]
emily has quit [Ping timeout: 252 seconds]
promach3 has quit [Ping timeout: 244 seconds]
madushan1000 has quit [Ping timeout: 260 seconds]
jryans has quit [Ping timeout: 260 seconds]
oter_ has quit [Ping timeout: 264 seconds]
fevv8[m] has joined #yosys
vidbina has joined #yosys
rjo has joined #yosys
emily has joined #yosys
jryans has joined #yosys
promach3 has joined #yosys
madushan1000 has joined #yosys
<lambda> mwk: ...what *does* the $macc cell do? The closest thing to documentation I can find is simlib, and that's 100 lines of verilog
<mwk> ... multiply and accumulate
<mwk> tbh I don't remember how exactly it works
<lambda> sure, but how do the ports work
<lambda> I'll just concur with "not a particularly clean approach" then
<mwk> but in general: it is a sum of multiple products
<mwk> the `A` input contains all the multiplication inputs, concatenated
<mwk> and the CONFIG parameter kind of describes how to cut up `A` into pieces to be multiplied / added
<mwk> the `B` input is uhhh, for carry inputs, I guess?
<lambda> yeah, uh, I'd rather not
<mwk> it may yet turn out to be the best solution
<whitequark> do we actually need $mem?
<mwk> well there's the simulation issue
<whitequark> i would like to get rid of it so that formal verification of CPUs stops breaking due to fake comb loops
<lambda> mwk: I'll leave that particular bucket of joy for someone else
<whitequark> hmm
<mwk> $mem can be simulated, $memwr+... can not
<whitequark> is it a hard requirement that every internal cell be simulatable?
<whitequark> you're using write_verilog anyways
<whitequark> just teach write_verilog about those cells
<whitequark> which by the way i believe should happen in either case
<mwk> yeah, that could work
<lambda> cxxrtl is probably the only simulator for RTLIL anyway
<mwk> lambda: write_verilog+iverilog is a simulator for RTLIL
<lambda> but not directly, there won't be a $mem in the verilog output
<whitequark> yep
<mwk> or +xsim (or pick your own propetriary simulator), which happens to be the only way to simulate stuff with weird hard primitives
<mwk> but, agreed, handling that stuff in write_verilog could be the right way to go
<whitequark> i mean, it's already handled in write_verilog whichever way you look at it
<whitequark> the only thing you lose is "structural verilog output" which is not well-defined in first place
<mwk> true
<whitequark> any simulator that can only take a "structural" netlist can't process yosys' $mem model anyways
<corecode> oh i guess there is no support for ice40 ultra lite?
<corecode> boo
<ZirconiumX> It can't be inferred
<ZirconiumX> That doesn't mean it's "not supported"
<whitequark> we're discussing right now an improvement that ought to solve that problem
<awygle> corecode: it is pretty easy to add it, if you'd like to work on that
<whitequark> wait, both i and ZirconiumX seem to have misread the request
<ZirconiumX> It's maybe a little vague
dys has quit [Ping timeout: 265 seconds]
vidbina has quit [Ping timeout: 244 seconds]
Asu has quit [Ping timeout: 256 seconds]
mwk has quit [Ping timeout: 256 seconds]
mwk has joined #yosys
emeb has quit [Quit: Leaving.]