whitequark changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/ | Bridged to #yosys:matrix.org
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
cr1901_ has joined #yosys
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ is now known as cr1901
lexano has quit [Ping timeout: 264 seconds]
lexano has joined #yosys
ec has quit [Remote host closed the connection]
ec has joined #yosys
nelgau has quit [Read error: Connection reset by peer]
nelgau has joined #yosys
<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)
<lofty> cr1901: hmm...
<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)
<cr1901> Okay, I can thankfully duplicate in a container. And thankfully outside of the container I get the expected 1276 LUT count
<cr1901> now to figure out the differences between oss-cad-suite and "the yosys I compile once per week"
<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)
<cr1901> Mine: UC Berkeley, ABC 1.01 (compiled Oct 14 2023 11:21:23)
<cr1901> CAD Suite: UC Berkeley, ABC 1.01 (compiled Nov 24 2023 01:45:46)
<cr1901> How do I get the commit hash from yosys-abc?
<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
<cr1901> So same yosys, same ABC, same OS, gives different results
<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
<cr1901> The logs are virtually identical until abc9 runs
<cr1901> at which point the abc9 I'm using in CI starts performing a bit worse than the one I have locally
<lofty> cr1901: are you explicitly calling abc9?
<cr1901> No, I ran yosys
<lofty> how did you run yosys
<cr1901> Gimme a sec to paste
<cr1901> script
<cr1901> "$YOSYS" -q -l top.rpt top.ys
<cr1901> I should prob check if the ilang files are identical
<lofty> cr1901: I see the problem
<lofty> abc9-by-default is not in oss cad suite
<lofty> so this is the ABC dff flow
<lofty> not the ABC9 dff flow
<cr1901> ABC dff can be combined with ABC9 flow?
<lofty> no
<lofty> they run different flows
<lofty> this is not ABC9, this is ABC
<cr1901> Well both logs say "executing ABC9"
<cr1901> 1/2*
<cr1901> Why didn't it error out when the ABC9 flow was called if it doesn't exist in oss-cad-suite?
<lofty> because the ABC9 flow was not called
<cr1901> Huh, weird
<lofty> as I said: <lofty> abc9-by-default is not in oss cad suite
<lofty> so this is abc-by-default
<cr1901> (Both logs say "Executing ABC9", so that's why I'm confused)
<cr1901> want me to upload them?
<lofty> sure.
<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
<lofty> Okay, I do see one big change between the two
<lofty> good is compiled with clang; bad is compiled with gcc
<cr1901> Reverse, but yes
<lofty> and, well, Yosys is known to have some small variances between compilers
<cr1901> I was afraid of that.
<lofty> Or perhaps ABC does, but either way
<cr1901> In other words, I'm running too close to the ragged edge of disaster
* lofty smiles thinly
<lofty> it could be worse
<lofty> I could be pulling out the very last idea I have to optimise things >.>
<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.
<cr1901> I'll probably allow "continue-on-failure" in CI for now
<lofty> I completely understand
<cr1901> Yea, I am _not_ out of ideas. I am out of fuel :P.
<cr1901> I am _not_ out of ideas on my end*
<lofty> I guess I have a few tricks left, maybe
<lofty> (maybe)
<cr1901> (Really, a big problem is RV's insistence that illegal opcodes have to be handled. There's SO GD many of them
<lofty> isn't that why SERV *doesn't* handle them? :p
<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
<lofty> It's a little amusing to me that you're not the only microcoded RV core that I know of
<cr1901> Someone on a retro discord I passively watch is doing one in TTL chips IIRC
<cr1901> Oh, Eric has been well aware of Sentinel for months. I use his microcode assembler
<cr1901> Like hell I was writing my own
<lofty> I would probably have used near's `bass` assembler if I was doing this, but yeah
<lofty> cr1901: I mean, I have the ultimate last-ditch optimisation technique, but it's a little hard to take seriously :p
<cr1901> I will live with the breakage for now, thanks :P
<cr1901> https://github.com/cr1901/sentinel/issues/2 This will have to do for now.
<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?
<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
<lofty> checking if those match up seems like a good start
<lofty> beware that ABC is a *mess* of undefined behaviour though
<cr1901> Is that equivalent to -nocleanup or should it be used in conjunction?
<cr1901> And also: Basically, will I be wasting Alan's time if I open an issue after doing some debugging?
<lofty> cr1901: abc9.debug implies -nocleanup
<lofty> and no, I don't think you'll be wasting Alan's time
<Myrl-saki> How do I use CSDECODE? Does it count as like tristate, or?
<Myrl-saki> (For reading, specifically)
<Myrl-saki> (I want to get rid of the output multiplexer, because that seems to be part of my critical path.)
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys