ChanServ changed the topic of #yosys to: Yosys Open SYnthesis Suite: https://github.com/YosysHQ/yosys/ | Channel logs: https://libera.irclog.whitequark.org/yosys/
tpb has quit [Remote host closed the connection]
tpb has joined #yosys
strobokopp has joined #yosys
stroboko1p has quit [Ping timeout: 244 seconds]
peepsalot has joined #yosys
peeps[zen] has quit [Ping timeout: 272 seconds]
Xark_ is now known as Xark
tlwoerner has quit [Remote host closed the connection]
tlwoerner has joined #yosys
trabucayre has quit [Read error: Connection reset by peer]
trabucayre has joined #yosys
somlo_ has joined #yosys
somlo has quit [Read error: Connection reset by peer]
jryans has quit [Remote host closed the connection]
promach[m] has quit [Read error: Connection reset by peer]
emilazy has quit [Write error: Connection reset by peer]
jophish has quit [Read error: Connection reset by peer]
promach[m] has joined #yosys
jryans has joined #yosys
emilazy has joined #yosys
jophish has joined #yosys
toshywoshy has quit [Ping timeout: 272 seconds]
toshywoshy has joined #yosys
tlwoerner_ has joined #yosys
TFKyle has quit [Ping timeout: 268 seconds]
tlwoerner has quit [Ping timeout: 272 seconds]
TFKyle has joined #yosys
ZipCPU has quit [Ping timeout: 264 seconds]
<tnt> Is there a way to force yosys to use 0 for all undefined init values of registers ?
ZipCPU has joined #yosys
FabM has joined #yosys
Ultrasauce has quit [Ping timeout: 252 seconds]
Ultrasauce has joined #yosys
e_ter is now known as eater
strobokopp has quit [Ping timeout: 252 seconds]
strobokopp has joined #yosys
<mwk> tnt: setundef -init -zero
<mwk> it's somewhat inconvenient to use though; it has to be used after proc and before technology mapping to target cells
<mwk> something like `hierarchy -auto-top; proc; setundef -init -zero; synth_ecp5' should work, I guess
<tnt> mwk: tx, I'll keep that in mind. Testing another theory ATM.
<tnt> For a bit of context, I'm trying to figure out why the Hackaday badge gateware doesn't work anymore. Works when built with 2019 toolchain, not with recent one.
<mwk> ok, that's worrying
<tnt> I narrowed it down to 9a4f420b4b8285bd05181b6988c35ce45e3c979a in yosys somehow causing the CPU in there to fail multiply instructions.
<mwk> ... that's going to be one of mine, isn't it
<tnt> ATM it's very possible that this change just caused some undefined-behavior change causing the issue rather than being an actual bug in yosys.
<mwk> ah, of course it is
<mwk> so, ecp5
<tnt> yes.
<mwk> opt_dff is of course the most likely culprit, but there's a slight possibility that the other minor change (moving fsm call upwards) could trigger something to be recognized as FSM that wasn't before
<mwk> do you have a repo link?
<tnt> in the `soc` subdir.
<tpb> <https://x0.no/4uxj8> (at github.com)
<tnt> I must warn you though that ... like many badges ... schedule was tight so it's not always the best code.
<tnt> I seem to have isolated the issue to pcpi_fastmul_dsp.v What I did was build that module independently using both "known good" and "known bad" toolchain, running it through synth_ecp5 and writing the result to verilog.
<tnt> Then I ran the build of the rest of the codebase using the "known bad" toolchain, including that pre-built module instead of its sources.
<tnt> And the one using pre-built with bad toolchain fails and the one using the pre-built with good toolchain (but still using bad toolchain for all the rest) works.
<tpb> <https://x0.no/4uxj9> (at github.com)
<gatecat> but nextpnr should be doing proper timing analysis of DSPs now
<tnt> (note I'm using 'good toolchain' / 'bad toolchain' as shortcuts here ... not implying anything else)
<tnt> Line 90 there was a <= vs = error ... I fixed that already, but didn't change result.
<gatecat> say you increase 3 to 4 or 5 here (if I understand what it's doing) does the 'bad' toolchain work? https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/9b24c061f50e22a111c7a73bfdd24c0d52ca5b5d/soc/pcpi_fastmul_dsp.v#L128
<tnt> gatecat: yeah, I hadn't read that comment that seems ... weird.
<tpb> <https://x0.no/4uxj9> (at github.com)
<tnt> Let me try that.
<tnt> (At this point it's mostly curiosity and make sure the issue is indeed with the code and not the tools because the real solution is just to remove that pcpi mul thing and let the internal one from picrorv32 do the job. Back inthe days it wasn't inferring DSP but now it does)
<tnt> gatecat: bumped it to 5 ... still fails.
<gatecat> hmm
<gatecat> seems fairly innocent code so I'm a bit surprised it's hitting a bug
<tnt> I'm re-doing my check with the two distrinct pre-synth .v files to confirm I didn't screw up.
<tnt> If that confirms itself, I might try to go for a post-synth simulation
<tnt> yup. same result.
<tnt> If you want a look : http://people.osmocom.org/~tnt/stuff/haddbg/ Logs & resulting .v from working/non working case.
<tpb> Title: Index of /~tnt/stuff/haddbg/ (at people.osmocom.org)
<tnt> Ah damn, no model for MULT18X18D
<tnt> Ah both files produce identical results in simulation.
<tnt> Outstanding.
<tnt> If anyone has got an idea of what to try next, I'm all ears.
<tnt> Huh ... trying the good pre-built module with a very recent (latest oss-cad-suite nightly), I now get ERROR: Assert `!aig_map.count(bit)' failed in backends/aiger/xaiger.cc:435
<mwk> are you using abc9?
<tnt> yes
<tnt> ok, so that has nothing to do with the pre-built module, I get that same ERROR with the vanilla sources.
<tnt> oh, my bad, that's not oss-cad-suite, some other yosys so disregard.
tlwoerner_ has quit [Quit: Leaving]
tlwoerner has joined #yosys
somlo_ is now known as somlo
FabM has quit [Quit: Leaving]
FabM has joined #yosys
adamhord- has quit [Ping timeout: 245 seconds]
adamhorden has joined #yosys
agg has quit [Ping timeout: 245 seconds]
agg has joined #yosys
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #yosys
adamhord- has joined #yosys
adamhorden has quit [Ping timeout: 245 seconds]
adamhorden has joined #yosys
adamhord- has quit [Ping timeout: 268 seconds]
FabM has quit [Quit: Leaving]
<tnt> I am loosing my mind.
<tnt> pcpi_wr and pcpi_ready should be identical ... looking in the presynth block, they come from different FF but those 2 FFs are identical (all same connection to all ports, same params).
<tnt> If in the top level instead of connecting each independently, I connect both to the same output ... it fails.
lkcl_ has joined #yosys
Guest16 has joined #yosys
Guest16 has quit [Ping timeout: 250 seconds]
Guest16 has joined #yosys
<tpb> Title: --- test.v.bad 2021-06-10 22:09:26.961987347 +0200+++ test.v 2021-06-10 22:18: - Pastebin.com (at pastebin.com)
<tnt> So instead of "assign pcpi_ready = pcpi_wr_i;", I instead duplicated (cut&paste + change instance name) the TREILLIS_FF that outputs pcpi_wr_i and made the new one output to pcpi_ready directly.
<tnt> That's enough to go from non-working to working.
<gatecat> this definitely has nextpnr bug vibes
<gatecat> can you put the files (working/not working json, lpf and output config files) somewhere for me to look tomorrow ?
<tnt> Really ? I would really have thought yosys. The fact that pcpi_ready and pcpi_rd are "different" (i.e. it can't tell they are the same) prevents some optimization.
<gatecat> oh, I misunderstoof
<tnt> This change is in the "presynthed" pcpi_mul block. The whole thing is then fed to yosys with all the rest of the sources.
<gatecat> *misunderstood
<gatecat> yeah, that could definitely be a Yosys bug too
<tnt> yeah, sorry, I wasn't super clear about the context. it was a follow up on all previous tests.
<tnt> Trying to diff the resulting json is useless though :/ even such a minor changes completely changes the output.
<gatecat> yeah, usually for stuff like this I look at the post-synthesis, or intermediate steps of synthesis, Verilog (with -norename) and manually compare the relevant signal cones
<tnt> There is nearly 240 LUT4 less ..
<gatecat> mmm interesting
Guest16 has quit [Quit: Guest16]
<tnt> I put all the latest stuff in http://people.osmocom.org/~tnt/stuff/haddbg/
<tpb> Title: Index of /~tnt/stuff/haddbg/ (at people.osmocom.org)
<gatecat> thanks!
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #yosys
<tnt> Ah, I reproduced the issue in post-synth simulation !
somlo has quit [Ping timeout: 252 seconds]
somlo has joined #yosys
<tpb> <https://x0.no/4uxnv> (at people.osmocom.org)
<tnt> Everythign needed to reproduce in simulation both working / failing case.
<tnt> (I've included the results of running it here .vcd and .log as well)
<mwk> tnt: fyi I've added this on my list and will look into this sometime this week if it doesn't get resolved first
<tnt> mwk: ack. I'm still trying to narrow it down further, but the best I'd ever be able to come up with is a smaller reproducer. My knowledge of yosys internal is definitely too weak than to ever find the issue.
<tnt> (I'm just really wondering how nobody hit that in 10 months ... at this point I only have picrorv32 and this pcpi mut thing and nothing else in there, so it's gotta be a bug in yosys and not the verilog code)