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
lexano has quit [Ping timeout: 255 seconds]
mewt has quit [Quit: leaving]
mewt has joined #yosys
<famubu[m]> Thanks. Using abc9 instead of abc changes the output quite a bit (or so I think).
<famubu[m]> What's the difference between the two? They are both the same tool, right? I guess it's used in different modes as was mentioned earlier.
<famubu[m]> And device utilisation report from nextpnr for an trivial example I tried shows LUT5,6,7,8. But my FPGA has only LUT4. Is that a problem?
<famubu[m]> Sipeed tang nano 9K
<famubu[m]> is the board I'm trying.
<famubu[m]> Is there any way by which I can get around this?
<famubu[m]> These were the yosys commands that I was using: https://bpa.st/4HBQ
<tpb> Title: View paste 4HBQ (at bpa.st)
<famubu[m]> Got error at command 10 (abc9).
<famubu[m]> Is it that my design is too big to fit in my FPGA?
<famubu[m]> Without the abc9 command the error doesn't show up.
nak has quit [Ping timeout: 252 seconds]
nak has joined #yosys
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Client Quit]
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Client Quit]
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Changing host]
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Client Quit]
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Client Quit]
tarikhamedovic has joined #yosys
pepijn_web has joined #yosys
tarikhamedovic has quit [Ping timeout: 256 seconds]
lexano has joined #yosys
tarikhamedovic has joined #yosys
tarikhamedovic has quit [Ping timeout: 256 seconds]
tarikhamedovic has joined #yosys
pepijn_web has quit [Quit: Client closed]
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
tarikhamedovic has quit [Quit: Client closed]
<lofty> famubu[m]: so, there seems to be a fairly big misunderstanding going on here
<lofty> If you run "help synth_gowin" you can see all the commands that it runs
<lofty> Which includes pretty much all of the commands you're trying to run before it
<lofty> If you're doing this to learn how a Yosys synthesis pass works, I'm happy to break everything down for you
<lofty> But if you're just trying to synthesise things for your Tang Nano 9K, you only need to run synth_gowin
<lofty> With that out the way
<lofty> LUT5/6/7/8: it's true that Gowin devices have LUT4s, but they have muxes which let you combine LUT4s into bigger LUTs. so, no problem there.
<tpb> Title: Setting up a flow for ABC9 - YosysHQ Yosys 0.44-dev documentation (at yosyshq.readthedocs.io)
<lofty> (which is all done as part of the Gowin simulation library, so you can just do `read_verilog -lib -specify +/gowin/cells_sim.v`)
bjorkintosh has joined #yosys
bjorkintosh has quit [Changing host]
bjorkintosh has joined #yosys
Adrien[m] has joined #yosys
<Adrien[m]> Hi, about abc9 I'd like to raise a questionWith an intern we've noticed that activating abc9 with `synth_xilinx` can produce a much larger design, by something like 2.5x when summing LUT counts in final resource usage report (will be able to confirm once holidays are over).
<Adrien[m]> I know abc9 flow is marked experimental, but to that extent really ?
<Adrien[m]> RAM usage and processing time are also much higher.
<lofty> Adrien[m]: I think I might know why
<lofty> more or less, delay and area are inversely correlated; a lower-delay solution consumes more area because there is less timing slack available
<lofty> my suspicion is that ABC9 has found a *much* lower-delay solution than ABC, and as a result, area went up
<lofty> if you add `scratchpad -set abc9.D N` (where N is a delay target in picoseconds; I would say roughly half your intended clock period), then you should be able to recover a lot of area
<gatecat> this might also be a consequence of synth_xilinx not flattening the design
<gatecat> this means you generally have more, smaller modules, so the critical path that ABC sees is shorter
<gatecat> and therefore it's more aggressively optimising for delay than it needs to, particularly as it can't see the "real" critical path as all it sees are the individual submodules
<gatecat> you could compare the two with -flatten as well and see if there's a difference - usually I'd expect a decent improvement with abc9 on xilinx, because it tends to be more sensible about using wide LUTs (MUXF7/8)
<Adrien[m]> lofty gatecat Thank you for the insight. We will have a look.
<lofty> Adrien[m]: who's "we" in this instance?
<Adrien[m]> The intern and me. Probably mostly me given that the intern will have his next year to begin
<Adrien[m]> In the end we decided to always keep the hierarchy in test designs, because designs were not worse, and RAM usage and synth time were much lower. This is critical when doing synthe
<Adrien[m]> ... synthesis within embedded system and under 512 MB of RAM total
nonchip has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
nonchip has joined #yosys
lexano has quit [Ping timeout: 255 seconds]