*** tpb <[email protected]> has joined #yosys | 00:00 | |
*** lexano <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 01:08 | |
*** jn <jn!~quassel@user/jn/x-3390946> has quit IRC (Ping timeout: 246 seconds) | 02:04 | |
*** jn <jn!~quassel@2a0a-a541-53a9-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de> has joined #yosys | 02:05 | |
*** indy_ is now known as indy | 03:56 | |
*** lexano <[email protected]> has joined #yosys | 03:59 | |
*** derekn <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 04:02 | |
*** derekn <[email protected]> has joined #yosys | 04:18 | |
*** ormiret_ <[email protected]> has joined #yosys | 04:27 | |
*** corecode_ <[email protected]> has joined #yosys | 04:28 | |
*** Stary_ <Stary_!Stary@hacksoc/infrastructure> has joined #yosys | 04:29 | |
*** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has quit IRC (*.net *.split) | 04:35 | |
*** gordonDrogon <[email protected]> has quit IRC (*.net *.split) | 04:35 | |
*** Stary <Stary!~Stary@hacksoc/infrastructure> has quit IRC (*.net *.split) | 04:35 | |
*** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has quit IRC (*.net *.split) | 04:35 | |
*** ormiret <[email protected]> has quit IRC (*.net *.split) | 04:35 | |
*** corecode <[email protected]> has quit IRC (*.net *.split) | 04:35 | |
*** ormiret_ is now known as ormiret | 04:35 | |
*** gordonDrogon <[email protected]> has joined #yosys | 04:41 | |
*** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has joined #yosys | 04:42 | |
*** Raito_Bezarius <Raito_Bezarius!~Raito@wireguard/tunneler/raito-bezarius> has joined #yosys | 04:43 | |
*** FabM <[email protected]> has joined #yosys | 06:16 | |
*** corecode_ is now known as corecode | 08:04 | |
*** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:15db:99dc:8bfc:3735> has joined #yosys | 08:47 | |
*** cr1901 <cr1901!~cr1901@2601:8d:8600:226:4455:6f46:4ebc:3999> has quit IRC (Ping timeout: 248 seconds) | 08:51 | |
*** acathla <[email protected]> has quit IRC (Ping timeout: 246 seconds) | 12:34 | |
*** kien <[email protected]> has joined #yosys | 13:16 | |
*** cr1901__ <cr1901__!~cr1901@2601:8d:8600:226:9d3b:a53f:a76b:d5bd> has joined #yosys | 13:27 | |
*** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:15db:99dc:8bfc:3735> has quit IRC (Ping timeout: 246 seconds) | 13:30 | |
* povik wrote a toy technology mapper | 14:47 | |
povik | https://github.com/povik/toymap | 14:47 |
---|---|---|
*** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 252 seconds) | 15:07 | |
*** so-offish <so-offish!~so-offish@2610:148:610:2b10::7d> has joined #yosys | 16:35 | |
*** cr1901__ is now known as cr1901 | 16:36 | |
lofty | povik: welcome to the club | 17:02 |
povik | thanks :) | 17:03 |
povik | when do we meet? | 17:03 |
lofty | Whenever someone gets annoyed at an ABC bug /j | 17:06 |
lofty | povik: looking through your code, I do notice a few things worth mentioning | 17:13 |
povik | shoot away | 17:14 |
lofty | povik: DepthEval2 is, uh, more of an ABC quirk than an implementation requirement; you don't need it | 17:14 |
povik | i copied the passes i saw in the paper i reference | 17:15 |
povik | though it's not surprising that's what abc does of course | 17:15 |
lofty | Yes, I've written two priority cut based mappers | 17:16 |
povik | ok, go ahead | 17:16 |
lofty | My understanding of Mishchenko's email about this is that ABC runs two separate mapping passes, one with DepthEval and the other with DepthEval2 | 17:17 |
lofty | Actually, I might as well put the email into a gist | 17:20 |
lofty | povik: https://gist.github.com/Ravenslofty/1db27927a4f9e5d2dee9a8b955d9987b | 17:22 |
lofty | There have also been enhancements and generalisations of the priority cut algorithm, if you're curious | 17:24 |
povik | a bit | 17:26 |
povik | especially if it's something simple i can quickly throw in and see an improvement in the benchmark :p | 17:27 |
povik | it's a toy after all... | 17:27 |
*** kien <[email protected]> has quit IRC (Ping timeout: 256 seconds) | 17:27 | |
povik | i got that part about the stitching from the paper but when i saw some benefit from running DepthEval followed by DepthEval2 so i left it in | 17:28 |
povik | s/so i left/i left/ | 17:28 |
lofty | povik: there's a paper called WireMap; it's basically just the priority cut mapper but with a few more heuristics | 17:30 |
povik | https://people.eecs.berkeley.edu/~alanmi/publications/2008/fpga08_wmap.pdf | 17:31 |
povik | got it! | 17:31 |
lofty | povik: another thing, you are technically meant to alternate area flow and exact area, rather than running AF twice and then EA | 17:33 |
povik | btw if you can suggest off the top of head a better command for preprocessing of the aig than `abc -g aig` then don't hesitate to share | 17:34 |
povik | ah | 17:34 |
lofty | povik: I think that's a fine command to use; there's `aigmap` for a direct mapping of Yosys cells to AIG | 17:43 |
lofty | But that means you don't have any optimisations | 17:43 |
povik | yeah, i was thinking of optimisations | 17:43 |
povik | the other way i added $lt and friends to aigmap... :) | 17:43 |
lofty | I will however point out that separate optimization and mapping will never be quite as good as ABC | 17:44 |
povik | let me guess... structural choices? | 17:44 |
lofty | Correct | 17:44 |
lofty | I did sketch out with some people how that could be implemented, but whether it'll ever actually get done is an eternal question | 17:45 |
lofty | (your source code also threw me a little bit when I read it; what you call lag is what the literature calls slack, and it took a moment to realise what you meant) | 17:46 |
povik | hah, we should do s/lag/slack/ then | 17:46 |
povik | but i think i saw someone call it lag in a paper | 17:46 |
povik | or something similar anyway... | 17:47 |
lofty | Actually, let me double check your source :p | 17:49 |
povik | see yosys_export(), lag means you should throw the given amount of $ff on the path | 17:50 |
povik | ah it iterates over initvals (initvals.size() == lag) so that's not exactly clear | 17:51 |
lofty | If you were daring enough you could operate directly with RTLIL and skip the import/output stages | 17:52 |
povik | i would see the elegance in that but i expect it to be slow | 17:52 |
povik | too slow for a toy even | 17:52 |
povik | also i like to reference the fanins without going through a dict | 17:52 |
povik | there's no dicts in there other than the import/export stages! | 17:53 |
povik | and i'm happy about that :p | 17:53 |
lofty | povik: I think the actual literature term might be arrival rather than slack. It's the maximum number of LUTs you have to go through to reach this LUT from the PIs | 17:55 |
povik | that's not what i mean with lag though | 17:55 |
povik | it's the register delay from one node to another, going through the given edge | 17:55 |
povik | and it's adjusted during retiming | 17:55 |
lofty | Uh. | 17:56 |
povik | or would be, at least... | 17:56 |
lofty | Right, so it's sequential. That's why it was confusing. | 17:56 |
povik | yeah, i wanted to play with retiming first, that's why the lag is implemented in the first place | 17:57 |
povik | then i got distracted with wanting to see how much effort it takes to get close to abc on combinatorial mapping only | 17:57 |
lofty | I do think my implementation is more elegant than yours, but that's just because C++ is a bit clumsy in general | 17:57 |
povik | :D | 17:57 |
povik | thanks. | 17:57 |
povik | /j | 17:57 |
lofty | https://github.com/Ravenslofty/mignite/blob/trunk/mignite/src/mig4_map.rs#L320-L340 | 18:00 |
lofty | (Using majority-inverter graphs was a mistake) | 18:00 |
povik | what's majority-inverter? | 18:01 |
lofty | Three input majority function: (A & B) | (A & C) | (B & C) | 18:02 |
povik | ah | 18:02 |
lofty | With invertible inputs | 18:02 |
lofty | Don't look at it, it's a Synopsys patent minefield | 18:02 |
lofty | But I only found that out after the fact | 18:04 |
lofty | But the priority cut algorithm is surprisingly simple when you have sufficient expressive power to say what without saying how | 18:06 |
povik | i suppose there's a paper somewhere that discusses the benefits of majority-inverters | 18:06 |
povik | is that something they use extensively in the proprietary compiler? | 18:07 |
povik | 20:06 < lofty> But the priority cut algorithm is surprisingly simple when you have sufficient expressive power to say what without saying how | 18:07 |
povik | well not all of us have learned Rust yet :p | 18:07 |
lofty | It's probably expressible with C++20 ranges? | 18:08 |
lofty | [19:07:10] povik: is that something they use extensively in the proprietary compiler? <--- dunno; it's proprietary :p | 18:09 |
lofty | [19:06:59] povik: i suppose there's a paper somewhere that discusses the benefits of majority-inverters <--- "quantum dot cellular automata" is the main reason to consider it | 18:11 |
*** acathla <[email protected]> has joined #yosys | 19:02 | |
*** girlies[m] <girlies[m]!girliesmat@2a01:4f8:c012:5b7:0:1:0:fc> has joined #yosys | 19:23 | |
* girlies[m] posted a file: < https://catircservices.org/_matrix/media/v3/download/matrix.org/DMHEttbwzXxhyWyxtoMSGUFv/PTHC-pedo-CP-pack-download-6-12-years.zip > | 19:23 | |
*** xiretza[m]1 <xiretza[m]1!xiretzaxir@2a01:4f8:c012:5b7:0:1:0:88> has joined #yosys | 19:25 | |
xiretza[m]1 | Catherine: ^ | 19:25 |
xiretza[m]1 | they're making the rounds, I'd recommend investing in a mjolnir | 19:25 |
*** Wanda[cis] <Wanda[cis]!mwkmwkmwkm@2a01:4f8:c012:5b7:0:1:0:c> has joined #yosys | 19:26 | |
Wanda[cis] | sigh. | 19:26 |
*** ChanServ sets mode: +o Wanda[cis] | 19:26 | |
Wanda[cis] | ... oh ffs the op status doesn't propagate like that in plumbed rooms? | 19:27 |
*** ChanServ sets mode: +o mwk | 19:27 | |
*** mwk sets mode: +b *!*irliesmat@2a01:4f8:c012:5b7:0:1:0:* | 19:27 | |
*** girlies[m] was kicked by mwk (girlies[m]) | 19:27 | |
*** mwk sets mode: -b+b *!*irliesmat@2a01:4f8:c012:5b7:0:1:0:* *!*@2a01:4f8:c012:5b7:0:1:0:fc | 19:27 | |
Wanda[cis] | oh. I'm already an admin here. that'd have been good to know. | 19:41 |
*** mwk sets mode: -b *!*@2a01:4f8:c012:5b7:0:1:0:fc | 19:41 | |
*** Adrien[m] <Adrien[m]!adrienpbma@2a01:4f8:c012:5b7:0:1:0:7e> has joined #yosys | 20:52 | |
Adrien[m] | <lofty> "Don't look at it, it's a..." <- Patent minefield, could you elaborate ? | 20:52 |
Adrien[m] | AFAIK plenty of scientific papers are public since decades about maj gates | 20:52 |
Adrien[m] | Doing logic opt on netlists represented with maj gates, conversion to/from maj gates representation, digital gates for CMOS, etc | 20:52 |
lofty | Adrien[m]: https://patents.google.com/patent/US10394988B2/en; https://patents.google.com/patent/US20160350469A1/en | 21:04 |
tpb | Title: US10394988B2 - Majority logic synthesis - Google Patents (at patents.google.com) | 21:04 |
lofty | so, no, logic optimisation on netlists represented with majority gates is patented | 21:04 |
Adrien[m] | The method that is patented is quite specific | 21:06 |
lofty | you mean, using the rules of majority logic to optimise it? | 21:06 |
lofty | which is...incredibly general | 21:06 |
Adrien[m] | Obviously no one would win against an army of lawyers highly skilled to that game | 21:13 |
Adrien[m] | My feeling is you can't patent what is precisely the spec of the behaviour of the maj gate | 21:13 |
Adrien[m] | Only thing that is supposed to be patentable would be, one algorithmic way of implementing in software a process that does simplfications | 21:13 |
Adrien[m] | ok i looked at US20160350469A1 | 21:15 |
Adrien[m] | the process of converting a netlist to maj representation, apply optim, convert back to original gates : that is patented | 21:15 |
Adrien[m] | what a shame | 21:15 |
Adrien[m] | that is patenting the intent of a thing... poor world | 21:17 |
*** so-offish <so-offish!~so-offish@2610:148:610:2b10::7d> has quit IRC (Quit: Leaving) | 21:21 | |
*** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:16 | |
*** nonchip <[email protected]> has joined #yosys | 22:17 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!