| *** tpb has joined #yosys | 00:00 | |
| cr1901_modern | Btw, I got this warning when compiling nextpnr-generic (for example) about strict aliasing for the pybindings: http://ix.io/2qc9 Is this bad? Or is it unavoidable in the context of whatever horrifying thing Boost does to generate Python bindings? | 00:02 |
|---|---|---|
| *** maartenBE has quit IRC | 00:11 | |
| *** futarisIRCcloud has joined #yosys | 00:17 | |
| *** maartenBE has joined #yosys | 00:47 | |
| az0re | mithro: Noice | 01:03 |
| mithro | cr1901_modern: Guess so :-P -- First step is to make them run in iverilog / verilator now | 01:08 |
| *** Degi has quit IRC | 01:59 | |
| *** Degi has joined #yosys | 02:00 | |
| *** citypw has joined #yosys | 02:26 | |
| *** FFY00 has quit IRC | 02:54 | |
| *** FFY00 has joined #yosys | 02:54 | |
| *** az0re has quit IRC | 03:49 | |
| *** az0re has joined #yosys | 04:06 | |
| *** AdamHorden has quit IRC | 04:47 | |
| *** AdamHorden has joined #yosys | 04:55 | |
| *** AdamHorden has left #yosys | 05:54 | |
| *** emeb_mac has quit IRC | 06:02 | |
| *** jakobwenzel has joined #yosys | 06:36 | |
| *** FabM has joined #yosys | 07:06 | |
| *** m4ssi has joined #yosys | 07:33 | |
| *** dys has quit IRC | 07:50 | |
| *** Asu has joined #yosys | 08:13 | |
| *** az0re has quit IRC | 09:16 | |
| *** citypw has quit IRC | 09:30 | |
| *** dys has joined #yosys | 09:53 | |
| whitequark | daveshah: PTAL at https://github.com/YosysHQ/prjtrellis/pull/145 | 10:05 |
| tpb | Title: Add WASI platform support by whitequark · Pull Request #145 · YosysHQ/prjtrellis · GitHub (at github.com) | 10:05 |
| whitequark | cr1901_modern: seems like a bug, but not sure | 10:06 |
| daveshah | whitequark: looks good, I'll take a proper look later. The multithreading stuff was just for fuzzing, so won't cause any loss with wasm | 10:10 |
| whitequark | yeah I assumed so | 10:12 |
| *** dys has quit IRC | 12:35 | |
| *** dys has joined #yosys | 13:56 | |
| whitequark | daveshah: i think #145 works well now | 14:05 |
| whitequark | btw it looks like nextpnr-ecp5 fails --test too | 14:08 |
| whitequark | same bel z check issue | 14:08 |
| whitequark | well, similar | 14:09 |
| *** X-Scale has quit IRC | 14:43 | |
| *** emeb has joined #yosys | 14:50 | |
| daveshah | whitequark: looks good, merged, thanks | 15:02 |
| daveshah | I will look into the test issue and set up CI to actually run them, at least for a few device variants | 15:02 |
| *** jfcaron_ has joined #yosys | 15:06 | |
| *** X-Scale has joined #yosys | 15:07 | |
| *** jakobwenzel has quit IRC | 15:09 | |
| *** jfcaron_ has left #yosys | 15:12 | |
| *** FabM has quit IRC | 15:19 | |
| *** laudecay1 has joined #yosys | 15:27 | |
| laudecay1 | hiya so i am writing verilog and i want to write a thing like systemverilog's count_bits or count_ones, but in as few gates as possible | 15:28 |
| laudecay1 | it gets mad when i say something like assign a = $countbits b; though | 15:28 |
| laudecay1 | is there some kind of shorthand for this in verilog? or do i need to write a module myself? | 15:29 |
| Lofty | You would have to write a module yourself | 15:30 |
| laudecay1 | ah ok | 15:30 |
| laudecay1 | thanks! | 15:31 |
| Lofty | It more or less boils down to add-reducing your input, except I don't think Verilog lets you do that directly | 15:31 |
| laudecay1 | what do you mean by add-reduce? | 15:32 |
| Lofty | Do you know how things like or-reduce work? | 15:33 |
| Lofty | (unary | on a signal) | 15:33 |
| laudecay1 | i'm currently writing code that produces verilog, and i need to be able to write it to support a variety of input and output sizes- so my plan was to make $INPUT_SIZE bitmasks, or them with the input, check equality of each, then add those | 15:33 |
| laudecay1 | i come from a math background with a bit of C, i know what bitwise | does if that's what you're asking | 15:34 |
| laudecay1 | oh like a map-reduce thing on the bits of the input | 15:34 |
| Lofty | x | y is binary | | 15:34 |
| Lofty | |x is like x[0] | x[1] | ... | 15:35 |
| laudecay1 | yeahhhhhh ok i haven't seen that notation but that's like a haskell fold | 15:35 |
| Lofty | Here you want x[0] + x[1] + x[2] ... | 15:35 |
| laudecay1 | yeah | 15:35 |
| Lofty | Though, have fun with expression widths there | 15:35 |
| laudecay1 | does verilog get mad about expression widths? | 15:35 |
| Lofty | No, Verilog *is* mad about expression widths | 15:35 |
| laudecay1 | :( | 15:36 |
| laudecay1 | big sad | 15:36 |
| laudecay1 | ok hm. | 15:36 |
| laudecay1 | i can handle breaking up expression widths, but | 15:36 |
| laudecay1 | how would you recommend doing this with fewest gates possible? | 15:36 |
| Lofty | By "gate" do you mean ASIC gates, or FPGA LUTs? | 15:37 |
| laudecay1 | like, would the "and it with a bunch of bitmasks" approach be reasonable? | 15:37 |
| Lofty | I don't think so, really. | 15:37 |
| laudecay1 | fewest 2-input and + not gates is ideal if possible | 15:38 |
| laudecay1 | i mean like boolean algebra gates | 15:38 |
| Lofty | I wouldn't recommend optimising for AIG | 15:39 |
| laudecay1 | i found this paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.534.7271&rep=rep1&type=pdf | 15:39 |
| laudecay1 | oh i have to optimize for boolean algebra gates- that's like the main constraint of the problem | 15:39 |
| * Lofty 's XY problem detector goes haywire | 15:40 | |
| laudecay1 | yeah...... i know it sounds wild | 15:40 |
| laudecay1 | we're turning x86 into boolean circuits | 15:40 |
| Lofty | The most optimal thing to use here is the, uh, `+` operator | 15:40 |
| laudecay1 | is a big part of the research | 15:40 |
| laudecay1 | in terms of boolean gates that it'll turn into under the hood? won't `+` overflow on each wire? | 15:41 |
| laudecay1 | like `b 1 + `b 1 = `b 0 right? | 15:41 |
| laudecay1 | `b 01 + `b 01 = `b 10 | 15:42 |
| laudecay1 | or am i misunderstanding | 15:42 |
| Lofty | The proposed circuit adds 1-bit results together, then 2-bit results together, then 4-bit results... | 15:42 |
| laudecay1 | ohhhhhh | 15:42 |
| Lofty | The `+` would produce half-adders for single input bits | 15:43 |
| Lofty | laudecay1: https://puu.sh/G0MmO/58e2239336.png <-- from Verilog-2001 standard; 2005 has an equivalent | 15:46 |
| Lofty | So to get a 2-bit result from addition, you need to zero-extend i and j to 2-bit, or assign it to a 2-bit wire | 15:47 |
| *** laudecay1 has quit IRC | 15:48 | |
| *** laudecay1 has joined #yosys | 15:50 | |
| laudecay1 | sorry my internet went out | 15:50 |
| laudecay1 | back | 15:50 |
| Lofty | <Lofty> laudecay1: https://puu.sh/G0MmO/58e2239336.png <-- from Verilog-2001 standard; 2005 has an equivalent | 15:50 |
| Lofty | <Lofty> So to get a 2-bit result from addition, you need to zero-extend i and j to 2-bit, or assign it to a 2-bit wire | 15:50 |
| laudecay1 | oh wow that's really helpful | 15:51 |
| laudecay1 | thank you so much!! | 15:51 |
| *** laudecay1 has quit IRC | 16:24 | |
| *** emeb_mac has joined #yosys | 16:53 | |
| *** emeb_mac has quit IRC | 16:58 | |
| *** dys has quit IRC | 17:39 | |
| *** kraiskil has joined #yosys | 17:46 | |
| *** laudecay1 has joined #yosys | 17:50 | |
| laudecay1 | hey im back- how do i test a circuit? i have the module signature here: module Population_count_32_to_32(input wire [0:31] a, output wire [0:31] b); | 17:51 |
| laudecay1 | i'd read -sv the file, then i run `eval -table a $abstract\Population_count_32_to_32` | 17:51 |
| laudecay1 | and i get an error it's failing to parse the table expression a | 17:52 |
| *** dys has joined #yosys | 18:07 | |
| *** laudecay1 has quit IRC | 18:12 | |
| *** AdamHorden has joined #yosys | 19:11 | |
| *** cr1901_modern has quit IRC | 19:20 | |
| *** cr1901_modern has joined #yosys | 19:24 | |
| *** kraiskil has quit IRC | 20:06 | |
| *** az0re has joined #yosys | 20:26 | |
| az0re | Hey so I was just perusing the README and I noticed that Yosys already depends on libboost-system-dev, libboost-python-dev, and libboost-filesystem-dev | 20:27 |
| az0re | Where exactly do these dependencies come from? | 20:27 |
| daveshah | libboost-python-dev will be from the python bindings | 20:28 |
| daveshah | seems like filesystem is python related too | 20:28 |
| az0re | So I guess the Boost situation is a bit more complicated than I thought... | 20:28 |
| daveshah | https://github.com/YosysHQ/yosys/blob/master/passes/cmds/plugin.cc#L29 | 20:28 |
| tpb | Title: yosys/plugin.cc at master · YosysHQ/yosys · GitHub (at github.com) | 20:28 |
| *** emeb_mac has joined #yosys | 20:29 | |
| az0re | I'm sure whitequark would vigorously oppose any further dependencies, but it's not a blanket ban | 20:29 |
| daveshah | It's only because the Python support is optional and disabled-by-default | 20:29 |
| az0re | daveshah: Yup, I see, thanks | 20:30 |
| az0re | Is that the only requirement in order to introduce a Boost dependency? That it be disabled by default? | 20:30 |
| daveshah | That kind of decision would be beyond my pay grade | 20:57 |
| *** Asu has quit IRC | 21:31 | |
| *** Asuu has joined #yosys | 21:31 | |
| *** m4ssi has quit IRC | 21:39 | |
| whitequark | az0re: i am vigorously opposed to anything from boost that is not absolutely necessary | 21:39 |
| whitequark | which is to say anything new from boost at all | 21:40 |
| whitequark | and i'd rather get rid of boost-python; there are better solutions available now, though i think they weren't there when this code was added | 21:40 |
| daveshah | Yeah the Yosys Python bindings are actually fairly old now | 21:41 |
| daveshah | They were held back for ages because of some academic dispute | 21:41 |
| whitequark | there's https://github.com/pybind/pybind11 now | 21:41 |
| tpb | Title: GitHub - pybind/pybind11: Seamless operability between C++11 and Python (at github.com) | 21:41 |
| whitequark | that's just 3 years old though, so it didn't exist when the bindings were added, i think | 21:42 |
| daveshah | I guess it would have just about done, but certainly not as well known | 21:42 |
| whitequark | perhaps not working as well as now either? | 21:43 |
| whitequark | the point being, i think boost-python was an appropriate choice *at the time it was added* | 21:43 |
| whitequark | but not anymore | 21:43 |
| daveshah | I should look at pybind11 for nextpnr at some point | 21:43 |
| whitequark | az0re: if you want to use something like std::filesystem we should find a polyfill that isn't boost-related | 21:43 |
| whitequark | remember how you (correctly) judged against using some hypergraph partitioner because it used scons? i would rather have to use scons when cross-compiling yosys than b2 | 21:44 |
| whitequark | yosys also has this annoying situation where it doesn't use cmake. with nextpnr it's generally easy to add any dependency that uses cmake because it can usually be vendored without much trouble, or just built in the same way as nextpnr itself | 21:45 |
| whitequark | yosys is special | 21:45 |
| whitequark | because of its baroque makefiles i think that any utility dependency should be just vendored into it, like i did with json11 | 21:46 |
| daveshah | Even with nextpnr I am preferring vendoring in these days, for stuff that isn't too big or fast-changing | 21:47 |
| whitequark | eigen? :) | 21:48 |
| whitequark | i currently actually install it into a temporary prefix in yowasp so that find_package() works | 21:49 |
| daveshah | Possibly a bit tricky with the blas dependency too | 21:50 |
| daveshah | But I can look into that for sure | 21:50 |
| whitequark | I... think the cross-builds don't use blas? | 21:50 |
| whitequark | hm | 21:50 |
| whitequark | I wonder if they run slower because of that | 21:51 |
| whitequark | certainly I can't compile asm-laden fortran into wasm | 21:51 |
| daveshah | The performance difference is tiny anyway | 21:51 |
| daveshah | I don't think it materially affects any ice40 or ecp5 design, it would be a small part of a small part of runtime | 21:51 |
| daveshah | For some reason I thought it requires blas, but if it works without then that sounds fine | 21:52 |
| daveshah | I rejected one sparse matrix solver because it was full of non-thread-safe f2c... | 21:53 |
| whitequark | works perfectly fine as just a single header | 21:53 |
| whitequark | i'm not actually sure how to make it use blas | 21:53 |
| whitequark | well not single header, headers alone | 21:54 |
| daveshah | That's easy enough then | 21:54 |
| *** Asuu has quit IRC | 22:10 | |
| emeb | OK - I've got a super sketchy design ganked from the web that uses a combinatorial loop to do some I2C stuff. It simulates fine and mostly synthesizes OK w/ yosys + nextpnr BUT I get this --- Warning: The network is combinational (run "fraig" or "fraig_sweep") | 23:13 |
| emeb | And that particular part of the design doesn't work right. | 23:14 |
| emeb | so the question is how to stick fraig_sweep in there? | 23:14 |
| emeb | (FWIW - this design apparently works in Xilinx tools, but requires some synthesis pragmas to preserve the structure - ie "keep" on the two nets of the loop) | 23:15 |
| Lofty | emeb: Don't | 23:32 |
| Lofty | The warning is harmless | 23:32 |
| Lofty | This is because the network is presented to ABC as a combinational cloud | 23:33 |
| emeb | Lofty: thx | 23:35 |
| Lofty | emeb: It actually seems the warning is out of date | 23:36 |
| Lofty | Yosys runs `ifraig`, and if you use what little help there is within ABC, `fraig -h` suggests `ifraig` as a replacement | 23:36 |
| emeb | Lofty: haha | 23:36 |
| emeb | well, this logic is nasty so I'm not surprised that it misbehaves in the real world. | 23:37 |
| Lofty | Yosys does support `(* keep *)` | 23:38 |
| Lofty | So | 23:38 |
| emeb | Lofty: heh - that fixed it. Thanks! | 23:43 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
