| *** tpb has joined #yosys | 00:00 | |
| *** craigo has joined #yosys | 00:00 | |
| mwk | lambda: not really, I've been... busy with other things | 00:20 |
|---|---|---|
| mwk | so far what I've done is just gathering the requirements in the issue | 00:20 |
| *** _whitelogger has quit IRC | 00:48 | |
| *** _whitelogger has joined #yosys | 00:50 | |
| *** FFY00 has quit IRC | 01:57 | |
| *** FFY00 has joined #yosys | 01:58 | |
| *** rlee287 has quit IRC | 02:05 | |
| *** Cerpin has quit IRC | 02:18 | |
| *** ktemkin_ has joined #yosys | 02:21 | |
| *** citypw has joined #yosys | 02:26 | |
| *** Twix has quit IRC | 02:28 | |
| *** promach3 has quit IRC | 02:28 | |
| *** whitequark has quit IRC | 02:28 | |
| *** Sarayan has quit IRC | 02:28 | |
| *** ktemkin has quit IRC | 02:28 | |
| *** ktemkin_ is now known as ktemkin | 02:28 | |
| *** Degi has quit IRC | 02:30 | |
| *** Degi has joined #yosys | 02:31 | |
| *** jryans has quit IRC | 02:32 | |
| *** rjo has quit IRC | 02:32 | |
| *** emily has quit IRC | 02:36 | |
| *** Cerpin has joined #yosys | 02:40 | |
| *** Degi has quit IRC | 02:51 | |
| *** Degi has joined #yosys | 02:52 | |
| *** promach3 has joined #yosys | 03:06 | |
| *** emily has joined #yosys | 03:06 | |
| *** rjo has joined #yosys | 03:07 | |
| *** jryans has joined #yosys | 03:15 | |
| *** BinaryLust has quit IRC | 03:52 | |
| *** BinaryLust has joined #yosys | 04:09 | |
| *** BinaryLust has quit IRC | 05:00 | |
| *** az0re has quit IRC | 05:29 | |
| *** kraiskil has joined #yosys | 05:48 | |
| *** craigo has quit IRC | 06:20 | |
| *** kgugala_ has joined #yosys | 06:26 | |
| *** emeb_mac has quit IRC | 06:27 | |
| *** kgugala has quit IRC | 06:29 | |
| *** kgugala_ has quit IRC | 06:30 | |
| *** kraiskil has quit IRC | 06:33 | |
| *** dys has joined #yosys | 06:45 | |
| *** dys has quit IRC | 07:07 | |
| *** az0re has joined #yosys | 07:17 | |
| *** N2TOH_ has joined #yosys | 08:34 | |
| *** N2TOH has quit IRC | 08:37 | |
| *** rswarbrick has joined #yosys | 09:04 | |
| 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. | 09:07 |
| daveshah | afaik, Yosys was pre-C++11 at one point | 09:08 |
| daveshah | unique_ptr should be fine now though, imo anyway | 09:08 |
| rswarbrick | Cool, makes sense to me. | 09:09 |
| *** Asu has joined #yosys | 09:25 | |
| *** madushan1000 has joined #yosys | 10:15 | |
| *** dys has joined #yosys | 10:33 | |
| *** vidbina has joined #yosys | 10:46 | |
| *** futarisIRCcloud has quit IRC | 11:24 | |
| *** vidbina has quit IRC | 11:46 | |
| *** rswarbrick has quit IRC | 12:16 | |
| *** vidbina has joined #yosys | 12:17 | |
| *** vidbina has quit IRC | 12:51 | |
| *** jfcaron_ has joined #yosys | 13:04 | |
| *** az0re has quit IRC | 13:09 | |
| lambda | mwk: alright, that's great - won't get very far without any set goals and requirements | 13:33 |
| *** emeb has joined #yosys | 13:36 | |
| ZirconiumX | Good luck, lambda | 13:50 |
| lambda | thanks :D still waiting for whitequark to reconnect to discuss her ideas, but I already see this won't be pretty | 13:56 |
| ZirconiumX | Start from the very basics and work upward, I suppose :P | 13:58 |
| ZirconiumX | Software development in Yosys is driven by people wanting to die on incredibly specific hills | 13:59 |
| lambda | well, at least there's passion | 14:00 |
| ZirconiumX | I maintain my own synthesis flow that - to my knowledge - nobody but me uses | 14:00 |
| ZirconiumX | So | 14:00 |
| *** vidbina has joined #yosys | 14:26 | |
| *** Twix has joined #yosys | 15:03 | |
| *** craigo has joined #yosys | 15:34 | |
| *** whitequark has joined #yosys | 15:44 | |
| ZirconiumX | wb whitequark | 15:45 |
| *** X-Scale` has joined #yosys | 15:46 | |
| *** X-Scale has quit IRC | 15:48 | |
| *** X-Scale` is now known as X-Scale | 15:48 | |
| mithro | Is there a way to create a verilog define which expands to nothing? | 16:22 |
| ZirconiumX | Why not just `define THING ? | 16:26 |
| lambda | hey whitequark, got some time to philosophise about memory? | 16:26 |
| mithro | ZirconiumX: That is what I /thought/ I could do - but it doesn't seem to work | 16:28 |
| *** vidbina has quit IRC | 16:28 | |
| *** vidbina has joined #yosys | 16:30 | |
| *** vidbina has quit IRC | 16:46 | |
| mithro | Oh, I need to put a ` in front of the macro value | 16:48 |
| whitequark | lambda: sure | 17:10 |
| whitequark | ZirconiumX: wb? | 17:10 |
| 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 | 17:15 |
| whitequark | do we? | 17:16 |
| lambda | I don't think any single cell normalization will work | 17:16 |
| whitequark | why? | 17:17 |
| whitequark | (i don't know that it will, and i don't know that it won't) | 17:17 |
| 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 | 17:19 |
| *** citypw has quit IRC | 17:19 | |
| ZirconiumX | whitequark: welcome back | 17:19 |
| ZirconiumX | lambda: I feel like handling "arbitrarily many" is impractical, but also missing the point a little | 17:20 |
| lambda | ZirconiumX: well, sure. but even two differently-sized read and write ports each would be a bit of a mess already | 17:21 |
| whitequark | i think $mem already has dynamically created module ports and parameters? | 17:21 |
| lambda | nope, not according to the manual at least | 17:22 |
| whitequark | oh, i see what you mean | 17:22 |
| whitequark | hmm | 17:22 |
| whitequark | lambda: have you read the discussion here? https://github.com/YosysHQ/yosys/issues/1134 | 17:23 |
| tpb | Title: Synthesis of asymmetric block RAMs · Issue #1134 · YosysHQ/yosys · GitHub (at github.com) | 17:23 |
| lambda | I have not, thanks | 17:23 |
| 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. | 17:24 |
| 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* | 17:30 |
| whitequark | fwiw i also at first leaned towards killing $mem | 17:38 |
| whitequark | but it seems that Claire wants it to stay | 17:38 |
| lambda | now, is it easier to hack around with $mem, or to change all consumers of $mem to use the split cells instead? | 17:40 |
| *** az0re has joined #yosys | 17:40 | |
| whitequark | i don't know if the latter will get merged | 17:44 |
| 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 | 17:44 |
| whitequark | i would ask first before spending any time implementing it | 17:45 |
| lambda | oh definitely, just trying to come up with designs that just satisfy the requirements at all | 17:46 |
| whitequark | ah, yeah | 17:46 |
| *** az0re has quit IRC | 17:46 | |
| *** az0re has joined #yosys | 17:51 | |
| *** rjo has quit IRC | 18:41 | |
| *** emily has quit IRC | 18:41 | |
| *** promach3 has quit IRC | 18:42 | |
| *** madushan1000 has quit IRC | 18:42 | |
| *** jryans has quit IRC | 18:42 | |
| *** oter_ has quit IRC | 18:45 | |
| *** fevv8[m] has joined #yosys | 19:20 | |
| *** vidbina has joined #yosys | 19:47 | |
| *** rjo has joined #yosys | 19:49 | |
| *** emily has joined #yosys | 19:49 | |
| *** jryans has joined #yosys | 19:49 | |
| *** promach3 has joined #yosys | 19:49 | |
| *** madushan1000 has joined #yosys | 19:49 | |
| 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 | 19:49 |
| mwk | ... multiply and accumulate | 19:50 |
| mwk | tbh I don't remember how exactly it works | 19:50 |
| lambda | sure, but how do the ports work | 19:50 |
| lambda | I'll just concur with "not a particularly clean approach" then | 19:51 |
| mwk | but in general: it is a sum of multiple products | 19:52 |
| mwk | the `A` input contains all the multiplication inputs, concatenated | 19:52 |
| mwk | and the CONFIG parameter kind of describes how to cut up `A` into pieces to be multiplied / added | 19:53 |
| mwk | the `B` input is uhhh, for carry inputs, I guess? | 19:53 |
| lambda | yeah, uh, I'd rather not | 19:54 |
| mwk | it may yet turn out to be the best solution | 19:55 |
| whitequark | do we actually need $mem? | 19:55 |
| mwk | well there's the simulation issue | 19:55 |
| whitequark | i would like to get rid of it so that formal verification of CPUs stops breaking due to fake comb loops | 19:55 |
| lambda | mwk: I'll leave that particular bucket of joy for someone else | 19:55 |
| whitequark | hmm | 19:56 |
| mwk | $mem can be simulated, $memwr+... can not | 19:56 |
| whitequark | is it a hard requirement that every internal cell be simulatable? | 19:56 |
| whitequark | you're using write_verilog anyways | 19:56 |
| whitequark | just teach write_verilog about those cells | 19:56 |
| whitequark | which by the way i believe should happen in either case | 19:57 |
| mwk | yeah, that could work | 19:57 |
| lambda | cxxrtl is probably the only simulator for RTLIL anyway | 19:57 |
| mwk | lambda: write_verilog+iverilog is a simulator for RTLIL | 19:58 |
| lambda | but not directly, there won't be a $mem in the verilog output | 19:58 |
| whitequark | yep | 19:58 |
| mwk | or +xsim (or pick your own propetriary simulator), which happens to be the only way to simulate stuff with weird hard primitives | 19:59 |
| mwk | but, agreed, handling that stuff in write_verilog could be the right way to go | 20:00 |
| whitequark | i mean, it's already handled in write_verilog whichever way you look at it | 20:00 |
| whitequark | the only thing you lose is "structural verilog output" which is not well-defined in first place | 20:01 |
| mwk | true | 20:01 |
| whitequark | any simulator that can only take a "structural" netlist can't process yosys' $mem model anyways | 20:01 |
| corecode | oh i guess there is no support for ice40 ultra lite? | 20:19 |
| corecode | boo | 20:19 |
| ZirconiumX | It can't be inferred | 20:19 |
| ZirconiumX | That doesn't mean it's "not supported" | 20:19 |
| whitequark | we're discussing right now an improvement that ought to solve that problem | 20:22 |
| awygle | corecode: it is pretty easy to add it, if you'd like to work on that | 21:00 |
| whitequark | wait, both i and ZirconiumX seem to have misread the request | 21:01 |
| ZirconiumX | It's maybe a little vague | 21:02 |
| *** dys has quit IRC | 21:15 | |
| *** vidbina has quit IRC | 22:16 | |
| *** Asu has quit IRC | 23:00 | |
| *** mwk has quit IRC | 23:34 | |
| *** mwk has joined #yosys | 23:36 | |
| *** emeb has quit IRC | 23:49 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!