| *** tpb <[email protected]> has joined #yosys | 00:00 | |
| *** strobokopp <[email protected]> has joined #yosys | 01:50 | |
| *** stroboko1p <[email protected]> has quit IRC (Ping timeout: 244 seconds) | 01:53 | |
| *** peepsalot <peepsalot!~peepsalot@openscad/peepsalot> has joined #yosys | 02:59 | |
| *** peeps[zen] <peeps[zen]!~peepsalot@openscad/peepsalot> has quit IRC (Ping timeout: 272 seconds) | 03:01 | |
| *** Xark_ is now known as Xark | 03:59 | |
| *** tlwoerner <[email protected]> has quit IRC (Remote host closed the connection) | 04:15 | |
| *** tlwoerner <[email protected]> has joined #yosys | 04:16 | |
| *** trabucayre <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:16 | |
| *** trabucayre <[email protected]> has joined #yosys | 04:16 | |
| *** somlo_ <[email protected]> has joined #yosys | 04:17 | |
| *** somlo <[email protected]> has quit IRC (Read error: Connection reset by peer) | 04:18 | |
| *** emilazy <emilazy!~emilazy@user/emilazy> has quit IRC (Write error: Connection reset by peer) | 04:47 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has quit IRC (Read error: Connection reset by peer) | 04:47 | |
| *** jryans <jryans!~jryansmat@2001:470:69fc:105::1d> has quit IRC (Remote host closed the connection) | 04:47 | |
| *** jophish <jophish!~jophish@2001:470:69fc:105::670> has quit IRC (Read error: Connection reset by peer) | 04:47 | |
| *** promach[m] <promach[m]!~promach@2001:470:69fc:105::ca1> has joined #yosys | 04:47 | |
| *** emilazy <emilazy!~emilazy@user/emilazy> has joined #yosys | 04:48 | |
| *** jryans <jryans!~jryansmat@2001:470:69fc:105::1d> has joined #yosys | 04:48 | |
| *** jophish <jophish!~jophish@2001:470:69fc:105::670> has joined #yosys | 04:48 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC (Ping timeout: 272 seconds) | 04:51 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #yosys | 04:52 | |
| *** tlwoerner_ <[email protected]> has joined #yosys | 05:02 | |
| *** TFKyle <[email protected]> has quit IRC (Ping timeout: 268 seconds) | 05:05 | |
| *** tlwoerner <[email protected]> has quit IRC (Ping timeout: 272 seconds) | 05:05 | |
| *** TFKyle <[email protected]> has joined #yosys | 05:10 | |
| *** ZipCPU <[email protected]> has quit IRC (Ping timeout: 264 seconds) | 05:42 | |
| tnt | Is there a way to force yosys to use 0 for all undefined init values of registers ? | 05:59 |
|---|---|---|
| *** ZipCPU <[email protected]> has joined #yosys | 06:09 | |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:677c:37ff:b977:c7ec> has joined #yosys | 06:52 | |
| *** Ultrasauce <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 07:07 | |
| *** Ultrasauce <[email protected]> has joined #yosys | 07:12 | |
| *** e_ter is now known as eater | 07:29 | |
| *** strobokopp <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 09:46 | |
| *** strobokopp <[email protected]> has joined #yosys | 09:53 | |
| mwk | tnt: setundef -init -zero | 10:06 |
| mwk | it's somewhat inconvenient to use though; it has to be used after proc and before technology mapping to target cells | 10:07 |
| mwk | something like `hierarchy -auto-top; proc; setundef -init -zero; synth_ecp5' should work, I guess | 10:08 |
| tnt | mwk: tx, I'll keep that in mind. Testing another theory ATM. | 10:14 |
| 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. | 10:15 |
| mwk | ok, that's worrying | 10:15 |
| tnt | I narrowed it down to 9a4f420b4b8285bd05181b6988c35ce45e3c979a in yosys somehow causing the CPU in there to fail multiply instructions. | 10:15 |
| mwk | ... that's going to be one of mine, isn't it | 10:16 |
| 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. | 10:16 |
| mwk | ah, of course it is | 10:16 |
| mwk | so, ecp5 | 10:19 |
| tnt | yes. | 10:20 |
| 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 | 10:21 |
| mwk | do you have a repo link? | 10:22 |
| tnt | https://github.com/Spritetm/hadbadge2019_fpgasoc | 10:22 |
| tnt | in the `soc` subdir. | 10:22 |
| tpb | <https://x0.no/4uxj8> (at github.com) | 10:22 |
| tnt | I must warn you though that ... like many badges ... schedule was tight so it's not always the best code. | 10:23 |
| 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. | 10:25 |
| 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. | 10:25 |
| gatecat | https://github.com/Spritetm/hadbadge2019_fpgasoc/blob/9b24c061f50e22a111c7a73bfdd24c0d52ca5b5d/soc/pcpi_fastmul_dsp.v#L125-L127 seems a bit ropey | 10:26 |
| 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. | 10:27 |
| tpb | <https://x0.no/4uxj9> (at github.com) | 10:27 |
| gatecat | but nextpnr should be doing proper timing analysis of DSPs now | 10:27 |
| tnt | (note I'm using 'good toolchain' / 'bad toolchain' as shortcuts here ... not implying anything else) | 10:27 |
| tnt | Line 90 there was a <= vs = error ... I fixed that already, but didn't change result. | 10:28 |
| 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 | 10:29 |
| tnt | gatecat: yeah, I hadn't read that comment that seems ... weird. | 10:29 |
| tpb | <https://x0.no/4uxj9> (at github.com) | 10:29 |
| tnt | Let me try that. | 10:29 |
| 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) | 10:32 |
| tnt | gatecat: bumped it to 5 ... still fails. | 10:37 |
| gatecat | hmm | 10:37 |
| gatecat | seems fairly innocent code so I'm a bit surprised it's hitting a bug | 10:38 |
| tnt | I'm re-doing my check with the two distrinct pre-synth .v files to confirm I didn't screw up. | 10:39 |
| tnt | If that confirms itself, I might try to go for a post-synth simulation | 10:41 |
| tnt | yup. same result. | 10:50 |
| tnt | If you want a look : http://people.osmocom.org/~tnt/stuff/haddbg/ Logs & resulting .v from working/non working case. | 10:53 |
| tpb | Title: Index of /~tnt/stuff/haddbg/ (at people.osmocom.org) | 10:53 |
| tnt | Ah damn, no model for MULT18X18D | 11:02 |
| tnt | Ah both files produce identical results in simulation. | 11:09 |
| tnt | Outstanding. | 11:09 |
| tnt | If anyone has got an idea of what to try next, I'm all ears. | 11:35 |
| 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 | 11:37 |
| mwk | are you using abc9? | 11:39 |
| tnt | yes | 11:39 |
| tnt | ok, so that has nothing to do with the pre-built module, I get that same ERROR with the vanilla sources. | 11:39 |
| tnt | oh, my bad, that's not oss-cad-suite, some other yosys so disregard. | 11:42 |
| *** tlwoerner_ <[email protected]> has quit IRC (Quit: Leaving) | 11:54 | |
| *** tlwoerner <[email protected]> has joined #yosys | 11:54 | |
| *** somlo_ is now known as somlo | 12:20 | |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:677c:37ff:b977:c7ec> has quit IRC (Quit: Leaving) | 14:13 | |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:bdbc:dcdf:f9bb:f9c> has joined #yosys | 14:15 | |
| *** adamhord- <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 16:26 | |
| *** adamhorden <adamhorden!~adam.hord@host31-52-149-183.range31-52.btcentralplus.com> has joined #yosys | 16:42 | |
| *** agg <[email protected]> has quit IRC (Ping timeout: 245 seconds) | 17:10 | |
| *** agg <[email protected]> has joined #yosys | 17:10 | |
| *** Lord_Nightmare <Lord_Nightmare!Lord_Night@user/lord-nightmare/x-3657113> has quit IRC (Quit: ZNC - http://znc.in) | 17:38 | |
| *** Lord_Nightmare <Lord_Nightmare!Lord_Night@user/lord-nightmare/x-3657113> has joined #yosys | 17:41 | |
| *** adamhord- <adamhord-!~adam.hord@host213-122-109-180.range213-122.btcentralplus.com> has joined #yosys | 17:43 | |
| *** adamhorden <adamhorden!~adam.hord@host31-52-149-183.range31-52.btcentralplus.com> has quit IRC (Ping timeout: 245 seconds) | 17:44 | |
| *** adamhorden <adamhorden!~adam.hord@host86-176-101-91.range86-176.btcentralplus.com> has joined #yosys | 18:36 | |
| *** adamhord- <adamhord-!~adam.hord@host213-122-109-180.range213-122.btcentralplus.com> has quit IRC (Ping timeout: 268 seconds) | 18:37 | |
| *** FabM <FabM!~FabM@2a03:d604:101:1200:bdbc:dcdf:f9bb:f9c> has quit IRC (Quit: Leaving) | 18:40 | |
| tnt | I am loosing my mind. | 18:50 |
| 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). | 18:51 |
| tnt | If in the top level instead of connecting each independently, I connect both to the same output ... it fails. | 18:52 |
| *** lkcl_ <[email protected]> has joined #yosys | 19:15 | |
| *** Guest16 <Guest16!~Guest16@cpc157431-lee215-2-0-cust373.7-1.cable.virginm.net> has joined #yosys | 19:57 | |
| *** Guest16 <Guest16!~Guest16@cpc157431-lee215-2-0-cust373.7-1.cable.virginm.net> has quit IRC (Ping timeout: 250 seconds) | 20:12 | |
| *** Guest16 <Guest16!~Guest16@cpc157431-lee215-2-0-cust373.7-1.cable.virginm.net> has joined #yosys | 20:17 | |
| tnt | https://pastebin.com/tfyiYyt5 | 20:25 |
| 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) | 20:25 |
| 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. | 20:26 |
| tnt | That's enough to go from non-working to working. | 20:26 |
| gatecat | this definitely has nextpnr bug vibes | 20:26 |
| gatecat | can you put the files (working/not working json, lpf and output config files) somewhere for me to look tomorrow ? | 20:27 |
| 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. | 20:27 |
| gatecat | oh, I misunderstoof | 20:28 |
| 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. | 20:28 |
| gatecat | *misunderstood | 20:28 |
| gatecat | yeah, that could definitely be a Yosys bug too | 20:28 |
| tnt | yeah, sorry, I wasn't super clear about the context. it was a follow up on all previous tests. | 20:28 |
| tnt | Trying to diff the resulting json is useless though :/ even such a minor changes completely changes the output. | 20:37 |
| 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 | 20:41 |
| tnt | There is nearly 240 LUT4 less .. | 20:45 |
| gatecat | mmm interesting | 20:46 |
| *** Guest16 <Guest16!~Guest16@cpc157431-lee215-2-0-cust373.7-1.cable.virginm.net> has quit IRC (Quit: Guest16) | 21:00 | |
| tnt | I put all the latest stuff in http://people.osmocom.org/~tnt/stuff/haddbg/ | 21:05 |
| tpb | Title: Index of /~tnt/stuff/haddbg/ (at people.osmocom.org) | 21:05 |
| gatecat | thanks! | 21:07 |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has quit IRC (Remote host closed the connection) | 21:35 | |
| *** GenTooMan <GenTooMan!~cyberman@2601:547:437f:e5c6:21f:5bff:fefe:a883> has joined #yosys | 23:17 | |
| tnt | Ah, I reproduced the issue in post-synth simulation ! | 23:21 |
| *** somlo <[email protected]> has quit IRC (Ping timeout: 252 seconds) | 23:24 | |
| *** somlo <[email protected]> has joined #yosys | 23:30 | |
| tnt | http://people.osmocom.org/~tnt/stuff/haddbg/had.tar.bz2 | 23:36 |
| tpb | <https://x0.no/4uxnv> (at people.osmocom.org) | 23:36 |
| tnt | Everythign needed to reproduce in simulation both working / failing case. | 23:36 |
| tnt | (I've included the results of running it here .vcd and .log as well) | 23:37 |
| 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 | 23:48 |
| 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. | 23:51 |
| 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) | 23:55 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!