| *** tpb has joined #yosys | 00:00 | |
| *** FFY00 has quit IRC | 01:03 | |
| *** FFY00 has joined #yosys | 01:05 | |
| *** craigo has quit IRC | 01:11 | |
| *** futarisIRCcloud has joined #yosys | 01:20 | |
| *** _whitelogger has quit IRC | 01:57 | |
| *** _whitelogger has joined #yosys | 01:59 | |
| *** Degi has quit IRC | 02:18 | |
| *** Degi has joined #yosys | 02:19 | |
| *** mithro has joined #yosys | 02:36 | |
| *** citypw has joined #yosys | 03:56 | |
| az0re | So, how negatively do people feel about bringing in Boost dependencies? | 04:23 |
|---|---|---|
| az0re | I am working on adding a `partition` command to Yosys, to split a (for now, flattened) techmapped module into multiple submodules with roughly balanced amounts of logic in each partition, with an objective to minimize the number of cut edges. In other words, it's an implementation of balanced hypergraph partitioning. | 04:25 |
| az0re | This is an NP-complete problem, but thankfully there are good heuristics for it. | 04:25 |
| az0re | There are AFAIK only two reasonable libraries that could be included in Yosys: KaHIP ( https://github.com/KaHIP/KaHIP ) and minipart2 ( https://github.com/Coloquinte/minipart2 ) | 04:27 |
| tpb | Title: GitHub - KaHIP/KaHIP: The graph partitioning framework KaHIP -- Karlsruhe High Quality Partitioning. (at github.com) | 04:27 |
| az0re | These are both MIT licensed | 04:27 |
| az0re | However, including minipart2 in Yosys would bring in some Boost dependencies, and including KaHIP would bring in Scons and an old version (!) of OpenMPI | 04:28 |
| az0re | So neither is particularly ideal... Guidance would be appreciated | 04:28 |
| whitequark | az0re: very negatively | 05:31 |
| whitequark | cross-compiling Boost is a nightmare and if I have any say over this at all I would never agree on having it in Yosys | 05:32 |
| whitequark | it was bad enough in nextpnr | 05:32 |
| whitequark | (in fact I would like to rip it out of nextpnr if possible) | 05:32 |
| az0re | Is the best option to rely on an external executable, then? Of course, then the command only works if the other program is installed | 05:52 |
| sorear | "minimizing the number of cut edges" is an oversimplification of the objective (we care a lot about timing, too, and depending on exactly what you're doing it may be possible to multiplex) | 05:52 |
| sorear | and I question whether a library that _only_ minimizes the number of cut edges, is useful at all? | 05:53 |
| az0re | Oh sure, it's not the only objective | 05:53 |
| sorear | doesn't make sense to spend a huge amount of effort on a precise solution of an approximate problem | 05:53 |
| az0re | And you can specify vertex and edge costs | 05:54 |
| az0re | > doesn't make sense to spend a huge amount of effort on a precise solution of an approximate problem | 05:54 |
| az0re | ? | 05:54 |
| az0re | Neither try to give a precise solution | 05:54 |
| az0re | I am not sure exactly where you're coming from, BTW. I am not talking about using this for mapping, if that's what you're thinking. | 05:56 |
| whitequark | I would personally consider reimplementing the algorithms but usually I work on things I know will be directly useful | 05:56 |
| whitequark | this seems to be more of an experimental project, right? | 05:56 |
| az0re | Not really | 05:56 |
| sorear | I only know what you said above <I am working on adding a `partition` command to Yosys, to split a (for now, flattened) techmapped module into multiple submodules with roughly balanced amounts of logic in each partition, with an objective to minimize the number of cut edges. > | 05:56 |
| sorear | if pushed to guess I would say this is for SLRs, but it could be anything | 05:57 |
| whitequark | what's the intended domain of the project? | 05:57 |
| whitequark | i.e. who will be using it? | 05:57 |
| az0re | I intend to scale GLIFT optimization by partitioning | 05:57 |
| whitequark | glift is based on SMT solvers, right? | 05:58 |
| az0re | And for this, classic cut-minimized partitioning is probably ideal | 05:58 |
| whitequark | s/based on/uses/ | 05:58 |
| az0re | Yes | 05:58 |
| whitequark | so you're already relying on an external tool for those | 05:58 |
| az0re | Yes | 05:58 |
| az0re | However, the command is more general than just my particular application | 05:59 |
| whitequark | well, if it would be a part of some core synthesis or simulation flow, I would personally try to get it as seamless as possible, up to and including reimplementing the algorithms | 05:59 |
| whitequark | but if it's a part of a single flow that requires SMT solvers, then an external tool is fine | 06:00 |
| whitequark | that's my logic. | 06:00 |
| az0re | I'm fine with calling an external program for my application | 06:00 |
| az0re | But like you say, it is not the ideal implementation | 06:00 |
| az0re | And it's a general command that may be useful to expose directly | 06:01 |
| whitequark | okay, I can raise that question on a meeting tomorrow | 06:02 |
| az0re | Anyway I feel like KaHIP is also a no-go | 06:03 |
| az0re | It specifically requires an old version of OpenMPI... like, what? | 06:03 |
| az0re | Cool, thanks | 06:03 |
| daveshah | I am actually working on an open source permissive hypergraph partitioner for nextpnr | 06:29 |
| daveshah | Hopefully in a month or two this will be a viable option for Yosys, too | 06:29 |
| daveshah | Funnily enough I went through a similar evaluation process a couple of weeks ago | 06:30 |
| az0re | Hah, funny | 06:38 |
| az0re | What's the state? I'd be interested in using it if it's already working | 06:39 |
| az0re | (Even if it's not ready for merging to Yosys yet) | 06:39 |
| az0re | Also, FWIW, I can't seem to get KaHIP to work, but hMETIS and minipart2 work fine | 06:39 |
| daveshah | It's not quite working yet but maybe next week I will have something at that point | 06:40 |
| az0re | Cool beans | 06:41 |
| az0re | It takes a regular .hgr file? | 06:41 |
| daveshah | No, not yet, I was mostly interested in deeply embedding in nextpnr | 06:42 |
| az0re | I see | 06:43 |
| az0re | A shitty spec is available at http://glaros.dtc.umn.edu/gkhome/fetch/sw/hmetis/manual.pdf | 06:43 |
| daveshah | Thanks! | 06:43 |
| az0re | Nonono, thanks to you :) | 06:43 |
| az0re | Actually, probably the code is more obvious: https://gist.github.com/boqwxp/28e5ad04fa0ec0ef84ddd8062f84efc7/raw/ef31b2312ffb7140e512aac84fd596539a40e954/gistfile1.txt | 06:46 |
| az0re | At least for weighted-node non-weighted-edge hypergraphs | 06:46 |
| az0re | But anyway it's not complicated | 06:47 |
| daveshah | Yep, I already have a debug dump format that happens to be pretty similar already | 06:48 |
| *** emeb_mac has quit IRC | 07:01 | |
| *** jakobwenzel has joined #yosys | 07:47 | |
| *** Xark has quit IRC | 08:11 | |
| *** Xark has joined #yosys | 08:14 | |
| *** kraiskil has joined #yosys | 08:58 | |
| *** Asu has joined #yosys | 09:10 | |
| *** X-Scale` has joined #yosys | 10:27 | |
| *** X-Scale has quit IRC | 10:28 | |
| *** X-Scale` is now known as X-Scale | 10:28 | |
| *** N2TOH has quit IRC | 11:05 | |
| *** N2TOH has joined #yosys | 11:06 | |
| *** hitomi2500 has joined #yosys | 12:30 | |
| hitomi2500 | is it normal for Yosys to yield almost 4 times more LUTs than non-free alternative? Gowin tech, 550 LUTs in native tools and 1800 in Yosys | 12:39 |
| hitomi2500 | or maybe something is wrong with my verilog? | 12:40 |
| daveshah | Very possible | 12:44 |
| daveshah | RAM mapping issues could be the cause, or just something wrong with the Gowin rules | 12:45 |
| Lofty | hitomi2500: Take a look at my gowin_abc9 branch | 12:46 |
| Lofty | You can get notable improvements in delay/area from it | 12:49 |
| hitomi2500 | Ok, thanks, i'll try that | 12:50 |
| Lofty | (make sure to pass `-abc9` to `synth_gowin` with that) | 12:51 |
| *** jfcaron has joined #yosys | 13:26 | |
| hitomi2500 | Alas, no luck with gowin_abc9, the result is a bit different, but overall usage is almost the same. | 13:49 |
| Lofty | How about using `-abc9 -nowidelut`? | 14:02 |
| Lofty | ABC is very ambitious with using wide LUTs for performance | 14:03 |
| Lofty | hitomi2500: ^ | 14:03 |
| maartenBE | The .editorconfig of yosys doesn't set tab_width. Is it 4? | 14:04 |
| Lofty | maartenBE: user preference | 14:06 |
| hitomi2500 | Indeed, -nowidelut works a bit better, but still not much. It seems i'm missing something else here. | 14:08 |
| Lofty | hitomi2500: can you copy/paste your Yosys output log? | 14:13 |
| Lofty | (to a pastebin) | 14:14 |
| Lofty | Wondering if something is not being inferred properly | 14:14 |
| lambda | maartenBE: what does tab width have to do with aligning comments in #2164? | 14:14 |
| maartenBE | When using hard tabs to align them, they might not align if your tab width is 8 vs mine is 8 | 14:16 |
| maartenBE | *mine is 4 | 14:16 |
| hitomi2500 | It's more than a pastebin's limit of 512K | 14:16 |
| lambda | maartenBE: why not? where would you want to put those comments? | 14:17 |
| nengel | CodingReadme does say that tabs are 8 spaces but I certainly don't listen to it (way too many levels of nesting in yosys for that) | 14:17 |
| hitomi2500 | There are some strange errors about bram port's clock being incompatible. Maybe it's because i use single port RAM? | 14:18 |
| hitomi2500 | https://pastebin.com/N0WtmKfy | 14:18 |
| tpb | Title: 5.8. Executing MEMORY_BRAM pass (mapping $mem cells to block memories). Process - Pastebin.com (at pastebin.com) | 14:18 |
| maartenBE | Oh, I didn't see the CodingReadme. | 14:18 |
| mwk | maartenBE: whatever the tab width is, the field values will start at the same horizontal positions, so you can use spaces to align the commends | 14:19 |
| mwk | comments | 14:19 |
| maartenBE | In there, spaces are used to align comments | 14:19 |
| lambda | maartenBE: tabs can't be used for alignment (for obvious reasons), that's what spaces are for - tabs are only for indentation so that anyone can make their nesting as tight or wide as they want | 14:19 |
| mwk | that or just don't bother and use a single space everywhere | 14:19 |
| mwk | either way, you're overthinking it | 14:19 |
| maartenBE | lines 86-92 in there | 14:19 |
| *** josi has quit IRC | 14:40 | |
| *** josi has joined #yosys | 14:41 | |
| Lofty | hitomi2500: that's the problem; you can't use single port RAMs in Yosys | 14:44 |
| Lofty | They won't infer | 14:44 |
| daveshah | They will infer, just to dual port RAMs | 14:44 |
| Lofty | Hmm | 14:45 |
| daveshah | But the exact pattern may be wrong | 14:45 |
| hitomi2500 | They do infer, at least what's the stats say. I will convert them to dualport anyway, just to check the difference. | 14:46 |
| *** dys has joined #yosys | 14:58 | |
| maartenBE | I can reproduce my cxxrtl issue of yesterday: see https://github.com/YosysHQ/yosys/issues/2166 | 15:00 |
| tpb | Title: cxxrtl backend generates non-working c++ sources when NDEBUG=1 · Issue #2166 · YosysHQ/yosys · GitHub (at github.com) | 15:00 |
| maartenBE | dropping ENABLE_DEBUG makes it work again | 15:00 |
| maartenBE | aargh, dropping ENABLE_NDEBUG | 15:01 |
| daveshah | Interesting, I wonder if something is wrapped in an assert or something | 15:04 |
| Lofty | cc whitequark | 15:08 |
| *** az0re has quit IRC | 16:11 | |
| *** maartenBE has quit IRC | 16:33 | |
| *** maartenBE has joined #yosys | 16:39 | |
| *** hitomi2500 has quit IRC | 16:40 | |
| *** citypw has quit IRC | 16:54 | |
| *** az0re has joined #yosys | 17:04 | |
| *** emeb has joined #yosys | 17:10 | |
| lambda | I think I heard there was a dev meeting today - any news about the memory redesign? :) | 17:29 |
| *** indy has quit IRC | 17:41 | |
| *** jakobwenzel has quit IRC | 18:34 | |
| *** bwidawsk is now known as thehardway | 18:52 | |
| *** _whitelogger has quit IRC | 20:00 | |
| *** _whitelogger has joined #yosys | 20:02 | |
| *** X-Scale` has joined #yosys | 20:11 | |
| *** ronyrus_ has joined #yosys | 20:14 | |
| *** ZirconiumX has joined #yosys | 20:14 | |
| *** Ekho- has joined #yosys | 20:14 | |
| az0re | So what's the official way to select a module programmatically? | 20:18 |
| *** X-Scale has quit IRC | 20:18 | |
| *** Lofty has quit IRC | 20:18 | |
| *** qu1j0t3 has quit IRC | 20:18 | |
| *** sensille has quit IRC | 20:18 | |
| *** Kamilion has quit IRC | 20:18 | |
| *** Ekho has quit IRC | 20:18 | |
| *** daddesio has quit IRC | 20:18 | |
| *** thardin has quit IRC | 20:18 | |
| *** ronyrus has quit IRC | 20:18 | |
| *** X-Scale` is now known as X-Scale | 20:18 | |
| *** Ekho- is now known as Ekho | 20:19 | |
| az0re | I see Design::select(), but it's not clear what type T2 is supposed to be or what "member" should be to select the whole module | 20:20 |
| az0re | Should I just do it manually, like `design->selection_stack.back().select(module);`? | 20:21 |
| *** ZirconiumX is now known as Lofty | 20:22 | |
| az0re | Or should I add a `Design::select(T1 *module)` to go along with the existing `Design::select(T1 *module, T2 *member)`? | 20:24 |
| *** qu1j0t3 has joined #yosys | 20:25 | |
| az0re | Yeah OK I understand now, that existing Design::select() exclusively for module members. | 20:27 |
| *** y2kbugger has quit IRC | 20:34 | |
| *** esden has quit IRC | 20:35 | |
| *** elms has quit IRC | 20:36 | |
| *** thoughtpolice has quit IRC | 20:36 | |
| *** esden has joined #yosys | 20:38 | |
| *** ovf has quit IRC | 20:40 | |
| *** tannewt has quit IRC | 20:41 | |
| *** y2kbugger has joined #yosys | 20:42 | |
| *** y2kbugger has quit IRC | 20:47 | |
| *** esden has quit IRC | 20:48 | |
| *** y2kbugger has joined #yosys | 20:52 | |
| *** Kamilion has joined #yosys | 20:52 | |
| *** kraiskil has quit IRC | 20:56 | |
| *** Asu has quit IRC | 21:18 | |
| *** Asu has joined #yosys | 21:19 | |
| *** y2kbugger has quit IRC | 21:24 | |
| *** tannewt has joined #yosys | 21:35 | |
| *** Asuu has joined #yosys | 21:35 | |
| *** esden has joined #yosys | 21:36 | |
| *** Asu has quit IRC | 21:36 | |
| *** ovf has joined #yosys | 21:37 | |
| *** y2kbugger has joined #yosys | 21:39 | |
| *** Asuu has quit IRC | 21:54 | |
| *** FFY00 has quit IRC | 21:56 | |
| *** FFY00 has joined #yosys | 21:56 | |
| *** elms has joined #yosys | 22:06 | |
| *** jfcaron has quit IRC | 22:07 | |
| *** thoughtpolice has joined #yosys | 22:13 | |
| whitequark | adding an overload for selecting a module seems fine | 22:44 |
| *** emeb has quit IRC | 23:25 | |
| *** emeb_mac has joined #yosys | 23:28 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!