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
ec has quit [Remote host closed the connection]
ec has joined #yosys
peeps[zen] has quit [Remote host closed the connection]
peeps[zen] has joined #yosys
peeps has joined #yosys
DX-MON has quit [Quit: I'm not disconnecting, you're disconnecting!]
DX-MON has joined #yosys
peeps[zen] has quit [Read error: Connection reset by peer]
FL4SHK has quit [Ping timeout: 252 seconds]
FL4SHK has joined #yosys
peeps is now known as peeps[zen]
bpye has quit [Ping timeout: 256 seconds]
bpye has joined #yosys
FabM has joined #yosys
FabM has joined #yosys
FabM has quit [Changing host]
lexano has quit [Ping timeout: 255 seconds]
lexano has joined #yosys
lexano has quit [Remote host closed the connection]
lexano has joined #yosys
<cr1901> I abc9 supposed to be strictly better (number of LUTs) than abc? I have a design where it's strictly worse (to be released soon). Is that worth a bug report? Idk how to minimize it tho.
<cr1901> I don't feel like adding "-noabc9" because I don't want to pin to "the yosys 3 commits ago or newer as of this writing" as a dep, but...
<cr1901> s/better/smaller/ s/worse/larger/ (better/worse is subjective. Smaller is what I want)
<tnt> cr1901: It's definitely not strictly better for me either.
<tnt> What's the target btw ?
<cr1901> ICE40HX1K
<tnt> Ok, so default type is good. Because a downside of abc9 is needing to specify `-device xxx` (default is hx) for it to select the right timing.
<cr1901> This may just be something I need to live with. I made a refactor, and abc got larger after the refactor, and abc9 got smaller with the refactor
<cr1901> (both "after refactors" are larger than "abc before refactor" tho)
<lofty> Yeah, please file it
<lofty> cr1901: ^
<lofty> tnt: I'm not sure it's a downside when the alternative is ABC's "what's a timing"
<cr1901> Will do once the project's public (should be soon...). I may choose a non-HEAD commit b/c refactors change the degree that abc9 is larger than abc (but it's pretty consistent)
<lofty> If nothing else, YosysHQ are looking for benchmark designs to compare things on
<lofty> But having an "ABC9 performs worse here" benchmark means I can experiment with things
<cr1901> Well try this: http://gopher.wdj-consulting.com:70/paste/d50ff075-d091-4bb9-b677-8cfa2bfbbb09.txt 1082 LUTs w/ synth_ice40, 1041 LUTs w/ -noabc9
<cr1901> ~4% increase in size
<cr1901> 1227 ICESTORM_LCs w/ -noabc9, 1252 LCs w/ just plain 'synth_ice40'
<lofty> cr1901: I'm going to need a .pcf file too; nextpnr won't pack the SB_GB_IO otherwise
<lofty> cr1901: I get different numbers, but ABC9 is indeed bigger
<lofty> It does seem to have a higher Fmax though
<lofty> let's do some runs and compare.
<lofty> cr1901: just to confirm, it's cd_sync_clk12_0__i which is the clock to check, right?
<cr1901> no, you want to check cpu_clk
<lofty> there is no `cpu_clk`.
<cr1901> Ooo you mean in the PCF. then yes
<lofty> I mean in the nextpnr output :p
<lofty> because to me this looks like a classical case of "ABC9 found a higher Fmax solution with less timing slack available"
<cr1901> Yes, there's only one clock in the design (aside from a reset_less POR domain which uses the same clock)
<cr1901> And okay, but I don't want a higher Fmax if it means that I lose room for expansion
<lofty> do you want the good news or the bad news?
<lofty> cr1901: ^
<cr1901> bad mews
<cr1901> typo intended I guess
<lofty> the invocation to get ABC9 to do better than ABC is a little unwieldy involving some dark arts
<lofty> yosys -p "scratchpad -set abc9.D 83333; scratchpad -copy abc9.script.flow3 abc9.script; synth_ice40 -abc9 -dff -json abc9-delaytarget.ice40.json" -f verilog testcase.v
<lofty> results in a netlist using 11 fewer ICESTORM_LCs than ABC
<cr1901> I don't want this design to fit into hx1k on a technicality either. So if it involves poking abc9 internals or a horrific command line invocation, I will live w/ the size diff
<cr1901> hmmmm
<lofty> in english this is: "target a network delay of 83333 ps AKA 12 MHz; optimise as much as possible; pass DFFs to ABC9 so it can optimise through them"
<lofty> sort of the -O3 of ABC9
<cr1901> Well, I guess it's worth adding that for the sake of a demo/proof of concept
<cr1901> I'd rather see something like ISE's optimize "SPEED", "BALANCED", "AREA" options
<cr1901> I'm not sure I've ever used scratchpad
<lofty> cr1901: that'd be nice, but Yosys itself is not timing-driven, only ABC9 is
<lofty> so I think it'd be a bit misleading
<cr1901> What is the scratchpad, and why does it "magically" affect how the synthesis/abc9 script runs?
<cr1901> Lemme guess... passes are allowed to set their own internal vars
<cr1901> and scratchpad is the escape-hatch to mess w/ those vars
<lofty> cr1901: pretty much; normally the only way to fiddle with a pass' behaviour is via its command line, which gets set in stone inside the `synth_xxx` command
<lofty> so to let a user override behaviour without editing the source and recompiling, some passes - like `abc9` - accept configuration through the scratchpad
<cr1901> Well abc9.D and abc9.script are documented as part of the command-line params. But I can't find docs on abc9.script.flow3 (other than "it exists and is set by default")
<cr1901> (presumably -D and -script command-line params would override the scratchpad? But since synth_ice40 doesn't set those, abc9 defers to the scratchpad to get default values instead?)
<lofty> cr1901: But I can't find docs on abc9.script.flow3 <-- map the design directly, remember it, do light synthesis, map the design, remember it, do heavy synthesis, map the design, remember it, pick out the best parts of all the mappings
<lofty> but basically, it's just a copy of what the ABC `&flow3` command does, more or less
<lofty> cr1901: But since synth_ice40 doesn't set those <-- yeah, it looks in the scratchpad for a fallback value
<cr1901> I'd like to note that neither abc9.D nor abc.script have a default values (yosys -p 'scratchpad get ...")
<cr1901> So it must fallback to a default default (sic) value :P
<lofty> abc9.D does not have a default value; if you don't specify it it does not get passed to ABC9
<lofty> ...so ABC9 pretends you set it to 1.
<lofty> (with the difference that ABC9 will not issue a warning if it cannot meet the target set by abc9.D)
<cr1901> I guess my question is "what is the priority of the abc9 command for looking to fill the "script" and "D" vars, given that you can pass them either as command-line params to "abc9" pass or set them as part of the scratchpad (or do neither!)
<cr1901> ?*
<lofty> as for abc9.script, if it's not set, it gets copied from abc9.script.default
<cr1901> >abc9.script.default <-- okay that _is_ set
<lofty> there is even
<lofty> abc9.script.default.area and abc9.script.default.fast
<lofty> :p
<lofty> cr1901: judging by the following comment in the `abc9` pass source code
<lofty> \// get arguments from scratchpad first, then override by command arguments
ZipCPU has quit [Ping timeout: 260 seconds]
<cr1901> In other words, unless you clear abc9.script.default, you can't have abc9.script unset. But abc9.D can be unset without problems.
<cr1901> unless you clear abc9.script.default <-- probably shouldn't do that
<lofty> Yosys seems surprisingly resilient to having abc9.script.default cleared
<lofty> > ERROR: scratchpad entry "abc9.script.default" is a global constant
<cr1901> I feel like a lot of this should be documented, but not sure where
<cr1901> (_outside of the source code_)
ZipCPU has joined #yosys
ZipCPU has quit [Ping timeout: 255 seconds]
ZipCPU has joined #yosys
nelgau has quit [Ping timeout: 260 seconds]
FabM has quit [Ping timeout: 256 seconds]
nelgau has joined #yosys
kristianpaul has quit [Quit: WeeChat 3.5]
<cr1901> lofty: Honestly, even the -dff option alone is doing wonders without destroying timing
<lofty> cr1901: I usually find that -dff makes timing slightly worse, but does help with area. when I don't get a complaint about it exposing an existing bug in the design, anyway
<cr1901> Yea, it also took out a worrying number of FFs as well. But the design still works on my board, so... it's probably nothing
<cr1901> (like 30 FFs were removed by adding -dff)
<lofty> Have a little bit of faith in Alan to write correct code :p
<cr1901> Fiiiine :D
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys
ec has quit [Ping timeout: 240 seconds]
ec has joined #yosys