| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** kein <[email protected]> has joined #yosys | 01:32 | |
| *** kein <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 01:50 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 248 seconds) | 01:53 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 256 seconds) | 02:52 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 03:52 | |
| *** FabM <FabM!~FabM@2a03:d604:103:600:2e60:8c7c:e8fb:7990> has joined #yosys | 06:12 | |
| *** tux3 <tux3!~tux3@user/tux3> has quit IRC (Quit: ZNC 1.8.2 - https://znc.in) | 06:29 | |
| *** tux3 <tux3!~tux3@user/tux3> has joined #yosys | 06:52 | |
| *** nak <nak!~nak@yosys/nak> has quit IRC (Ping timeout: 246 seconds) | 08:15 | |
| Adrien[m] | Back to the discussion about mapping and ABC | 08:48 |
|---|---|---|
| Adrien[m] | There is a feature request I opened some time ago in Yosys repo, about optimizing combinatorial logic when all inputs can fit in one level of LUTs | 08:48 |
| Adrien[m] | https://github.com/YosysHQ/yosys/issues/3084 | 08:48 |
| Adrien[m] | I am still trying to understand if this should be a task for yosys, or for ABC | 08:51 |
| Adrien[m] | Certainly someone in this channel has clear understanding of the boundaries between yosys and ABC and could explain this to me ? | 08:51 |
| Adrien[m] | I may be able to assign an intern to this development, if only I could see through these software stacks a bit more clearly :D | 08:52 |
| corecode | is your proposal a simple (hierarchical) karnaugh map type thing? | 09:48 |
| corecode | does it have to use a hierarchy? | 09:49 |
| Adrien[m] | Yes, complete conversion of the component instance to plain lookup tables | 09:50 |
| Adrien[m] | That optim is also called memoization in software compilation field, if I'm correct | 09:50 |
| Adrien[m] | The hierarchy proides the boundaries of interest, provided by the developer | 09:51 |
| Adrien[m] | To cope with inexistent or insufficient cut-searching-algorithm in mapping tools | 09:51 |
| Adrien[m] | in that case, yosys and whatever backent mapping tools it is using. | 09:51 |
| Adrien[m] | s/backent/backend/ | 09:51 |
| corecode | i think it's a good option. doesn't have to be a standard pass | 10:24 |
| corecode | have it operate on the hierarchy, run it before the tree is flattened | 10:25 |
| corecode | rather than annotating boundaries and rediscovering them | 10:26 |
| lofty | Adrien[m]: I would disagree with your proposal, actually. | 10:35 |
| lofty | Suppose Yosys performs this transformation | 10:36 |
| lofty | ABC and especially ABC9 flows work in and-inverter graph form | 10:37 |
| lofty | So when Yosys has to give the design to ABC, it has to blow the LUT back into gates | 10:37 |
| lofty | Which is not that different from representing it as gates to begin with | 10:38 |
| corecode | so how can it be done | 10:39 |
| lofty | It can't. | 10:39 |
| lofty | If you make this optimisation you have to compromise at the Yosys/ABC boundary somehow | 10:39 |
| lofty | Either you blow the LUT to gates | 10:39 |
| corecode | that's silly tho to say that this optimization cannot be done | 10:40 |
| corecode | maybe it can't be done with the current structure | 10:40 |
| lofty | See, saying things like "it's silly to say this cannot be done" is the kind of thing that gets you a brusque "patches welcome" in response | 10:41 |
| lofty | so instead of ignoring my experience in the area would you like to rephrase? | 10:41 |
| corecode | can ports be marked to have an opportunistic cutting point for lut mapping later? | 10:41 |
| lofty | No. | 10:41 |
| corecode | why not? | 10:41 |
| lofty | You can't communicate this to ABC | 10:42 |
| corecode | nono, through | 10:42 |
| lofty | Let me guess | 10:42 |
| corecode | does the lut mapping happen in abc? | 10:42 |
| whitequark[cis] | you know, a long time ago I was told that a LUT mapper other than abc cannot be done | 10:42 |
| corecode | whitequark[cis]: and? | 10:42 |
| whitequark[cis] | and then it turned out that a nearly trivial pass converting fine gates to small LUTs and then combining those small LUTs into bigger ones gets you somewhere in the ballpark of abc. I think it was about 2x area and slightly lower Fmax | 10:43 |
| lofty | Your proposal is that Yosys instead does LUT mapping, which runs into the issue that you cannot then pass information into ABC; *all* optimisations would have to be entirely in Yosys | 10:43 |
| corecode | so what needs to happen to communicate this to abc? | 10:44 |
| whitequark[cis] | I think there's a lot of area to be explored in LUT mapping rather than defeatingly accepting that it can only be done by abc | 10:44 |
| lofty | Perhaps I should better say that to do this would be a serious effort requiring multiple people | 10:44 |
| whitequark[cis] | (I've attempted to explore it but at the time my health took a nosedive and so my attempt remains in the Yosys tree but it's not really usable) | 10:45 |
| lofty | whitequark[cis]: ABC's algorithms are state of the art. I'm all for reinventing the wheel to learn how wheels are made, but to get up to ABC parity is a challenge. | 10:45 |
| whitequark[cis] | I like a challenge | 10:46 |
| whitequark[cis] | I think I'm not alone in that, too | 10:46 |
| lofty | I've been paid pretty good money to try to match ABC by myself | 10:46 |
| lofty | I failed. | 10:46 |
| corecode | so can you modify abc? | 10:46 |
| whitequark[cis] | when I fail I stand up and try again | 10:47 |
| whitequark[cis] | eventually with enough persistence you succeed | 10:47 |
| whitequark[cis] | and advance the state of the art | 10:47 |
| lofty | when I fail I look for different jobs that can put food on the table | 10:47 |
| lofty | Anyway | 10:47 |
| Adrien[m] | You know I'm OK with a "patches welcome" answer :D | 10:48 |
| Adrien[m] | As long as I can get a few guidelines about what part of what tool is doing what, because I'm new to all these internals and probably won't have time to deep dive myself. | 10:48 |
| lofty | If someone writes a priority cut mapping pass for Yosys, they have one piece of the optimisation triforce | 10:48 |
| whitequark[cis] | I'd like to see an improvement on abc (which by the way can compete with it not only in performance but also in usability) and it would be unfortunate if your failure discouraged others from doing it; so I'll do my best to encourage :) | 10:48 |
| corecode | why can't you add this to abc? | 10:48 |
| lofty | The other two pieces are structural choices and sequential mapping | 10:48 |
| lofty | corecode: ABC's code is miserable to work with. | 10:49 |
| lofty | It is C code trying to be C++ | 10:49 |
| corecode | ok | 10:50 |
| whitequark[cis] | it is also written by one person with a quirky style that's difficult to understand if you don't have his context in your head somehow | 10:50 |
| corecode | thats not a good reason not to try to implement something so seemingly trivial | 10:50 |
| lofty | Yes, "seemingly trivial" is the thing | 10:51 |
| whitequark[cis] | there are very few tests; take a look at recent commits to abc and you'll see what I mean | 10:51 |
| Adrien[m] | In many proprietary tools there is support for tool-specific attributes that developers can add to the RTL, saying how this module or instance should be handled | 10:52 |
| Adrien[m] | We could be selective at least this way, about tabulating some components instances | 10:52 |
| Adrien[m] | BTW having proper handling of usual KEEP or DONT_TOUCH attributes would be much welcome, so there may be a broader context in which that tabulating feature would fit nicely. | 10:52 |
| lofty | ABC is built up of a variety of "managers" which represent the netlist in different ways | 10:52 |
| lofty | These are all highly optimised and fragile and there is little documentation on them | 10:52 |
| lofty | Adrien[m]: Yosys already natively supports (* keep *) though. | 10:53 |
| Adrien[m] | lofty: I've had issues with it, so I should have a new look to it if it's supposed to work | 10:54 |
| jix | yosys's (* keep *) just makes sure the signal stays around it doesn't prevent optimizations from rewriting the fan-out of that signal to not use it anymore | 10:55 |
| lofty | corecode: here is just one of those managers you will need to modify for your seemingly trivial task: https://github.com/berkeley-abc/abc/blob/master/src/aig/gia/gia.h#L97-L244 | 10:55 |
| jix | which is fine if you want to make sure you still have that signal in simulation or FV traces, but doesn't cover a lot of use cases people have | 10:55 |
| lofty | whitequark[cis]: my failure was educational to me and I would very much like to try again, but first I have to remove my association of the task with a very bad work environment. | 11:01 |
| corecode | yea, it's code that does a lot of things | 11:01 |
| lofty | corecode: and now it must do even more | 11:02 |
| corecode | could it go into another manager? | 11:02 |
| corecode | maybe we should first figure out why it fails to get to the optimum solution | 11:02 |
| corecode | and sometimes it does not | 11:03 |
| corecode | but yea definitely looks like an abc task if you want to use abc | 11:03 |
| lofty | I think that might be a much easier problem to solve than trying to communicate things to ABC... | 11:03 |
| lofty | My guess? There's probably a bug with how it handles whiteboxes. | 11:03 |
| corecode | Adrien[m]: maybe that's a first task for an intern. create several test cases that succeed/fail when trivial aspects are changed, and record all kinds of internal data from yosys and abc | 11:06 |
| lofty | I did my best to create a set of test cases in my own LUT mapper | 11:06 |
| lofty | They're kind of painful to debug | 11:07 |
| *** Psentee <Psentee!~psentee@user/psentee> has quit IRC (Quit: Off) | 11:42 | |
| *** Psentee <Psentee!~psentee@user/psentee> has joined #yosys | 11:43 | |
| Adrien[m] | <jix> "yosys's (* keep *) just makes..." <- Aha yes indeed. And the DONT_TOUCH has the purpose of ensuring both "sides" of the signal are kept separate. | 11:52 |
| Adrien[m] | Originally I wanted to guide the yosys/abc mapper by putting such attributes where I intended to have my LUT boundaries, this is another way of guiding the mapper about where interesting boundaries are supposed to be. | 11:52 |
| povik | 12:43 < whitequark[cis]> and then it turned out that a nearly trivial pass converting fine gates to small LUTs and then combining those small LUTs into bigger ones gets you somewhere in the ballpark of abc. I think it was about 2x area and slightly lower Fmax | 11:54 |
| povik | is that what flowmap is? | 11:54 |
| Adrien[m] | The DONT_TOUCH (if it's not implemented or honored yet) has rather same level of importance than the hierarchy boundary feature, to my feeling | 11:56 |
| Adrien[m] | Now I'm used to design my own netlist-level components, instantiate my LUTs, so that I can let automated toos yosys/abc handle the rest of the less-critical glue logic... it's extremely time-consuming ! | 11:56 |
| whitequark[cis] | <povik> "12:43 < Catherine> and then it..." <- nono, flowmap is the more complicated one | 12:04 |
| whitequark[cis] | the simple one is a techmap file I don't quite recall how it's called plus the opt_lut pass | 12:04 |
| whitequark[cis] | I can dig it out for you later; busy right now | 12:04 |
| whitequark[cis] | the result was way better than what I thought it would be and it provided ample motivation to do something that wasn't completely trivial | 12:05 |
| whitequark[cis] | unfortunately for flowmap I completely fucked up the internal representation for the pass; it needs a complete rewrite | 12:05 |
| whitequark[cis] | I was working at the edge of my competency at the time and made a few design mistakes I didn't realize until much later | 12:06 |
| povik | would the different representation improve QoR? | 12:06 |
| whitequark[cis] | "it's complicated" | 12:07 |
| whitequark[cis] | with a different representation flowmap-r (note the -r) would actually work properly, and we could get results and evaluate them comparing against abc | 12:07 |
| povik | i tested the toy priority cut mapper against flowmap also and it seemed easy to beat | 12:07 |
| povik | ah, i don't think i invoked the -r variety | 12:07 |
| whitequark[cis] | so the reason I picked the flowmap paper is because it was the first one in my search results with an actual algorithm in it | 12:08 |
| povik | right | 12:08 |
| whitequark[cis] | my approach to this problem was essentially "spray and pray"; implement a bunch of papers, understand the tradeoffs, then combine it all into something nice | 12:08 |
| whitequark[cis] | flowmap itself basically unusable as an algorithm, for more than 4-LUTs the runtime becomes intractable | 12:08 |
| povik | i was surprised how close i got to abc with they toy, if you haven't checked that already | 12:08 |
| povik | s/they/the/ | 12:09 |
| whitequark[cis] | it was never intended to be the solution to replacing abc, it was just some thing I wrote and thought it could be useful to upstream | 12:09 |
| whitequark[cis] | povik: have not! got a link and some test results? | 12:09 |
| povik | https://github.com/povik/toymap | 12:09 |
| povik | that's what we were discussing with lofty yesterday | 12:09 |
| whitequark[cis] | the reason I wrote flowmap is to pave the path to better LUT mapping essentially | 12:09 |
| whitequark[cis] | at the time, I talked to gatecat and they told me that they don't think replacing abc is feasible at all | 12:10 |
| whitequark[cis] | and I wanted to prove them wrong (in a friendly way) | 12:10 |
| whitequark[cis] | not only by getting some results myself but by inspiring others to try too | 12:10 |
| whitequark[cis] | toymap seems exciting! | 12:11 |
| povik | :) | 12:11 |
| povik | i wrote it over few days trying to make techmapping seem less magical | 12:13 |
| povik | when i saw it's cutting up an AIG in one of mischenko's paper i knew i wanted to try it myself | 12:14 |
| povik | s/mischenko/Mishchenko/ | 12:14 |
| whitequark[cis] | very excited | 12:15 |
| *** nak <nak!~nak@yosys/nak> has joined #yosys | 12:16 | |
| jix | I'd really love to see (experiments with) more use of e-graphs in synthesis to avoid pass order problems or problems with optimizations undoing some manually tuned parts of the design or just undoing good choices of prior optimizations ... I know that abc already supports choices but it's not clear to me where abc actually makes use of them and there's not really any such concept in yosys | 12:16 |
| * povik googles e-graphs | 12:27 | |
| jix | The https://egraphs-good.github.io/ paper is a good intro and resparked their popularity but SMT solvers have been using e-graphs since forever | 12:29 |
| tpb | Title: egg (at egraphs-good.github.io) | 12:29 |
| povik | ok, printing that out for later | 12:30 |
| povik | uh, 33 pages | 12:30 |
| jix | the basic idea is that instead of doing rewrites you keep the previous and new version around using something that you can think of as choice nodes but using a nice representation to work with and keep things relatively compact | 12:31 |
| povik | right, what would be called structural choices in papers related to abc | 12:31 |
| jix | except that AFAICT from using abc, it's not really embracing it and doesn't use an internal representation tuned to make heavy use of it | 12:32 |
| povik | i guess one way to see the effect of it is to re-import the aig just before lut mapping and compare the results | 12:33 |
| *** philtor <[email protected]> has quit IRC (Remote host closed the connection) | 12:41 | |
| lofty | jix: well, things like abc9 flow3 depend pretty heavily on structural choices, so it seems to work fairly well in my experience | 12:50 |
| *** Psentee <Psentee!~psentee@user/psentee> has quit IRC (Quit: Off) | 12:52 | |
| jix | lofty: I haven't looked at that in particular as I mostly do FV stuff, and for that a lot of stuff doesn't support them at all and IIRC also some of the aig to aig optimizations would just discard them | 12:52 |
| *** Psentee <Psentee!~psentee@user/psentee> has joined #yosys | 12:54 | |
| jix | lofty: what's the corresponding paper to flow3 (if there is a specific one)? | 13:28 |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 14:05 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #yosys | 14:06 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Ping timeout: 248 seconds) | 14:49 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 14:59 | |
| *** strobo <[email protected]> has joined #yosys | 15:07 | |
| *** FabM <FabM!~FabM@armadeus/team/FabM> has quit IRC (Ping timeout: 240 seconds) | 15:52 | |
| *** Adrien[m] <Adrien[m]!adrienpbma@2a01:4f8:c012:5b7:0:1:0:7e> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:10 | |
| *** _catircservices <_catircservices!catircserv@2a01:4f8:c012:5b7:0:1:0:a9> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:10 | |
| *** whitequark[cis] <whitequark[cis]!whitequa_1@2a01:4f8:c012:5b7:0:1:0:4> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:10 | |
| *** Wanda[cis] <Wanda[cis]!mwkmwkmwkm@2a01:4f8:c012:5b7:0:1:0:c> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:10 | |
| *** xiretza[m]1 <xiretza[m]1!xiretzaxir@2a01:4f8:c012:5b7:0:1:0:88> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:10 | |
| *** sauce <[email protected]> has joined #yosys | 17:13 | |
| *** philtom <[email protected]> has joined #yosys | 17:16 | |
| *** philtom is now known as philtor | 17:16 | |
| *** philtor <[email protected]> has quit IRC (Quit: Leaving) | 17:24 | |
| *** philtor <[email protected]> has joined #yosys | 17:26 | |
| *** _catircservices <_catircservices!catircserv@2a01:4f8:c012:5b7:0:1:0:102> has joined #yosys | 17:40 | |
| *** ChanServ sets mode: +o _catircservices | 17:40 | |
| *** _catircservices1 <_catircservices1!catircserv@2a01:4f8:c012:5b7:0:1:0:102> has joined #yosys | 17:41 | |
| corecode | so how does abc deal with LUT blocks? | 17:42 |
| corecode | i.e. when i use a target specific lut instance | 17:42 |
| *** lexano <[email protected]> has joined #yosys | 17:45 | |
| *** _catircservices1 <_catircservices1!catircserv@2a01:4f8:c012:5b7:0:1:0:102> has quit IRC (Quit: Bridge terminating on SIGTERM) | 17:46 | |
| *** _catircservices <_catircservices!catircserv@2a01:4f8:c012:5b7:0:1:0:102> has quit IRC (Read error: Connection reset by peer) | 17:46 | |
| *** _catircservices <_catircservices!catircserv@2a01:4f8:c012:5b7:0:1:0:103> has joined #yosys | 17:46 | |
| *** ChanServ sets mode: +o _catircservices | 17:46 | |
| *** Sarayan <Sarayan!~galibert@2a01:e0a:c8b:e320:beae:c5ff:fee3:518f> has quit IRC (Remote host closed the connection) | 17:56 | |
| povik | you mean if you explicitly instance a target-specific LUT cell in your design, then run abc synthesis? | 18:44 |
| povik | i think those will be treated as blackboxes, maybe abc9 can consider those properly in the timing model | 18:44 |
| *** lkcl <[email protected]> has quit IRC (Quit: Leaving) | 19:12 | |
| corecode | so that could be used for Adrien's idea | 20:50 |
| *** Adrien[m] <Adrien[m]!adrienpbma@2a01:4f8:c012:5b7:0:1:0:7e> has joined #yosys | 20:53 | |
| Adrien[m] | I very often instanciate bare LUTs, carry, DSP, RAMB18/36 etc in my RTL dsigns | 20:53 |
| Adrien[m] | just to obtain precisely what I want to obtain | 20:53 |
| Adrien[m] | yosys and whatever is behind seem to know that this exists as-in in the FPGA. | 20:53 |
| Adrien[m] | and it is kept untouched in the design | 20:54 |
| corecode | Adrien[m]: i mean a pass before abc that will turn sections into blackbox luts | 20:55 |
| corecode | then abc can't optimize them away | 20:55 |
| lofty | corecode: blackbox cells are implemented by hiding them from ABC | 21:19 |
| lofty | which means they can't be optimised away, but they also mislead ABC as to the actual length of the path | 21:20 |
| Adrien[m] | <lofty> "which means they can't be..." <- Good to know. Thanks for pointing this out. | 21:59 |
| Adrien[m] | Then it would be very useful that ABC recognizes the primitives from its input design. | 21:59 |
| Adrien[m] | Do you mean the the mapper has some form of taking timing into account to determine appropriate boundaries for what should be grouped into LUTs ? | 22:01 |
| Adrien[m] | and if that is the case, does it try to favor the critical paths in priority ? | 22:03 |
| Adrien[m] | Finding documentation for abc internals does not seem easy... | 22:12 |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 22:17 | |
| *** nonchip <[email protected]> has joined #yosys | 22:17 | |
| lofty | [19:44:49] povik: i think those will be treated as blackboxes, maybe abc9 can consider those properly in the timing model <--- you could treat them as whiteboxes, I suppose | 22:22 |
| lofty | [23:01:21] Adrien[m]: Do you mean the the mapper has some form of taking timing into account to determine appropriate boundaries for what should be grouped into LUTs ? <--- yes, either LUT level or timing information provided to ABC (which is what forms ABC9) | 22:24 |
| lofty | [23:03:39] Adrien[m]: and if that is the case, does it try to favor the critical paths in priority ? <--- yes | 22:24 |
| lofty | The priority cut algorithm will always provide a depth-optimal result (modulo bugs) | 22:25 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!