| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** cr1901_ <cr1901_!~cr1901@2601:8d:8600:226:251c:b8f8:8826:7f04> has joined #yosys | 01:39 | |
| *** cr1901 <cr1901!~cr1901@2601:8d:8600:226:5021:bd23:1d17:ff62> has quit IRC (Read error: Connection reset by peer) | 01:39 | |
| *** cr1901_ is now known as cr1901 | 01:55 | |
| *** lexano <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 07:55 | |
| *** lexano <[email protected]> has joined #yosys | 08:08 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has quit IRC (Remote host closed the connection) | 09:44 | |
| *** ec <ec!~ec@gateway/tor-sasl/ec> has joined #yosys | 09:44 | |
| *** nelgau <[email protected]> has quit IRC (Read error: Connection reset by peer) | 13:39 | |
| *** nelgau <[email protected]> has joined #yosys | 13:40 | |
| cr1901 | lofty: https://github.com/cr1901/sentinel/actions/runs/6993303260/job/19025827724#step:16:16 Looks like I might have to disable the demo for now LOL (looks like "it depends on the yosys binary" whether the design fits or not) | 14:49 |
|---|---|---|
| lofty | cr1901: hmm... | 14:50 |
| cr1901 | I'll spin up a container at home and see if I can dup. At the very least, a Windoze build of yosys with the most recent commit as of 12 hours ago doesn't change the LC count from what I expect (1276) | 14:52 |
| cr1901 | Okay, I can thankfully duplicate in a container. And thankfully outside of the container I get the expected 1276 LUT count | 16:16 |
| cr1901 | now to figure out the differences between oss-cad-suite and "the yosys I compile once per week" | 16:16 |
| cr1901 | (Obligatory I should probably just switch to yowasp, but I still need a bunch of external tools so it'll be a weird hybrid of tools needed) | 16:17 |
| cr1901 | Mine: UC Berkeley, ABC 1.01 (compiled Oct 14 2023 11:21:23) | 16:19 |
| cr1901 | CAD Suite: UC Berkeley, ABC 1.01 (compiled Nov 24 2023 01:45:46) | 16:19 |
| cr1901 | How do I get the commit hash from yosys-abc? | 16:20 |
| cr1901 | Of course. It's the same ABC I have installed locally. Fabulous: https://github.com/YosysHQ/oss-cad-suite-build/actions/runs/6992668184/job/19024546417#step:5:85 | 16:49 |
| cr1901 | So same yosys, same ABC, same OS, gives different results | 16:49 |
| cr1901 | lofty: I have some logs if you're curious. I guess abc9 is using a different random seed/algorithm when compiled for the OSS Cad Suite versus mine. 1/2 | 17:02 |
| cr1901 | The logs are virtually identical until abc9 runs | 17:02 |
| cr1901 | at which point the abc9 I'm using in CI starts performing a bit worse than the one I have locally | 17:02 |
| lofty | cr1901: are you explicitly calling abc9? | 17:03 |
| cr1901 | No, I ran yosys | 17:03 |
| lofty | how did you run yosys | 17:03 |
| cr1901 | Gimme a sec to paste | 17:04 |
| cr1901 | http://gopher.wdj-consulting.com:70/paste/a355c2e9-47cd-41e5-a36d-959fbdac9c9d.txt | 17:04 |
| cr1901 | script | 17:04 |
| cr1901 | "$YOSYS" -q -l top.rpt top.ys | 17:04 |
| cr1901 | I should prob check if the ilang files are identical | 17:05 |
| lofty | cr1901: I see the problem | 17:06 |
| lofty | abc9-by-default is not in oss cad suite | 17:06 |
| lofty | so this is the ABC dff flow | 17:06 |
| lofty | not the ABC9 dff flow | 17:06 |
| cr1901 | ABC dff can be combined with ABC9 flow? | 17:07 |
| lofty | no | 17:08 |
| lofty | they run different flows | 17:08 |
| lofty | this is not ABC9, this is ABC | 17:08 |
| cr1901 | Well both logs say "executing ABC9" | 17:08 |
| cr1901 | 1/2* | 17:08 |
| cr1901 | Why didn't it error out when the ABC9 flow was called if it doesn't exist in oss-cad-suite? | 17:09 |
| lofty | because the ABC9 flow was not called | 17:09 |
| cr1901 | Huh, weird | 17:11 |
| lofty | as I said: <lofty> abc9-by-default is not in oss cad suite | 17:11 |
| lofty | so this is abc-by-default | 17:11 |
| cr1901 | (Both logs say "Executing ABC9", so that's why I'm confused) | 17:11 |
| cr1901 | want me to upload them? | 17:12 |
| lofty | sure. | 17:12 |
| cr1901 | Good: http://gopher.wdj-consulting.com:70/paste/50e0c6e1-80ad-4644-a6b8-05f05a51c250.txt | 17:12 |
| cr1901 | Bad (OSS Cad Suite, I have replaced paths to be identical to Good to reduce noise)): http://gopher.wdj-consulting.com:70/paste/d4488bed-af3c-44a9-ab60-e3231890d80e.txt | 17:13 |
| lofty | Okay, I do see one big change between the two | 17:14 |
| lofty | good is compiled with clang; bad is compiled with gcc | 17:15 |
| cr1901 | Reverse, but yes | 17:15 |
| lofty | and, well, Yosys is known to have some small variances between compilers | 17:15 |
| cr1901 | I was afraid of that. | 17:16 |
| lofty | Or perhaps ABC does, but either way | 17:17 |
| cr1901 | In other words, I'm running too close to the ragged edge of disaster | 17:18 |
| * lofty smiles thinly | 17:18 | |
| lofty | it could be worse | 17:18 |
| lofty | I could be pulling out the very last idea I have to optimise things >.> | 17:19 |
| cr1901 | There might be some low-hanging fruit left I can do, but I'm pretty set on locking the core as-is for now. I'm tired and want a break from working on it. | 17:20 |
| cr1901 | I'll probably allow "continue-on-failure" in CI for now | 17:21 |
| lofty | I completely understand | 17:21 |
| cr1901 | Yea, I am _not_ out of ideas. I am out of fuel :P. | 17:21 |
| cr1901 | I am _not_ out of ideas on my end* | 17:21 |
| lofty | I guess I have a few tricks left, maybe | 17:22 |
| lofty | (maybe) | 17:22 |
| cr1901 | (Really, a big problem is RV's insistence that illegal opcodes have to be handled. There's SO GD many of them | 17:22 |
| lofty | isn't that why SERV *doesn't* handle them? :p | 17:23 |
| cr1901 | Yea, I actually keep forgetting that SERV doesn't handle them. But by the time I first realized that, I'd already put all the illegal crap in the decoder and didn't feel like ripping it out lol | 17:24 |
| lofty | It's a little amusing to me that you're not the only microcoded RV core that I know of | 17:24 |
| cr1901 | Someone on a retro discord I passively watch is doing one in TTL chips IIRC | 17:25 |
| lofty | https://github.com/brouhaha/glacial | 17:25 |
| cr1901 | Oh, Eric has been well aware of Sentinel for months. I use his microcode assembler | 17:26 |
| cr1901 | Like hell I was writing my own | 17:26 |
| cr1901 | https://github.com/brouhaha/m5meta | 17:26 |
| lofty | I would probably have used near's `bass` assembler if I was doing this, but yeah | 17:27 |
| lofty | cr1901: I mean, I have the ultimate last-ditch optimisation technique, but it's a little hard to take seriously :p | 17:34 |
| cr1901 | I will live with the breakage for now, thanks :P | 17:34 |
| cr1901 | https://github.com/cr1901/sentinel/issues/2 This will have to do for now. | 18:03 |
| cr1901 | lofty: >Figure out why clang and gcc abc are diverging, if possible. <-- Just on a lark, is there anything I can do here, like run abc with debug options to see into it's internal state a bit? | 18:04 |
| lofty | cr1901: truthfully, I don't know, but there's `abc9.debug` as a scratchpad bool, which should preserve the intermediate files going to and from ABC | 18:11 |
| lofty | checking if those match up seems like a good start | 18:11 |
| lofty | beware that ABC is a *mess* of undefined behaviour though | 18:11 |
| cr1901 | Is that equivalent to -nocleanup or should it be used in conjunction? | 18:13 |
| cr1901 | And also: Basically, will I be wasting Alan's time if I open an issue after doing some debugging? | 18:13 |
| lofty | cr1901: abc9.debug implies -nocleanup | 19:06 |
| lofty | and no, I don't think you'll be wasting Alan's time | 19:06 |
| Myrl-saki | How do I use CSDECODE? Does it count as like tristate, or? | 22:33 |
| Myrl-saki | (For reading, specifically) | 22:39 |
| Myrl-saki | (I want to get rid of the output multiplexer, because that seems to be part of my critical path.) | 23:05 |
| *** nonchip <[email protected]> has quit IRC (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) | 23:21 | |
| *** nonchip <[email protected]> has joined #yosys | 23:21 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!