| *** tpb has joined #symbiflow | 00:00 | |
| *** futarisIRCcloud has joined #symbiflow | 00:31 | |
| *** citypw has joined #symbiflow | 03:23 | |
| mithro | kgugala: ping? | 03:58 |
|---|---|---|
| *** proteusguy has joined #symbiflow | 05:03 | |
| sf-slack1 | <kgugala> mithro: I'm here | 05:16 |
| *** Bertl_oO is now known as Bertl_zZ | 06:03 | |
| *** proteusguy has quit IRC | 07:57 | |
| *** kraiskil has joined #symbiflow | 08:08 | |
| *** proteusguy has joined #symbiflow | 08:09 | |
| *** kraiskil has quit IRC | 08:47 | |
| *** OmniMancer has joined #symbiflow | 09:09 | |
| *** citypw has quit IRC | 09:48 | |
| *** Bertl_zZ is now known as Bertl | 10:40 | |
| *** proteusguy has quit IRC | 10:59 | |
| *** futarisIRCcloud has quit IRC | 13:10 | |
| sf-slack1 | <tmichalak> Hello everyone, I started looking into creating a separate fuzzer for GFAN to get rid of one of the causes of unstability in the CI runs, namelly this one https://github.com/SymbiFlow/prjxray/issues/567 . My question here is whether I should create a fuzzer for GFAN feautures, like INT_L.GFAN0.BYP_BOUNCE1 or just break out the solution of BYP_ALT?.GFAN? from the 050-pip-seed fuzzer? | 13:49 |
| tpb | Title: INT FAN_ALT[0-9].GFAN0 solutions are still unstable · Issue #567 · SymbiFlow/prjxray · GitHub (at github.com) | 13:49 |
| sf-slack1 | <tmichalak> @litghost: I believe that you opted for creating a separate fuzzer for GFAN, because we could limit the solution size to 2 bits. But looking at the database https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/segbits_int_l.db#L2061 I don't see the GFAN bits fall into this category. | 13:55 |
| tpb | Title: prjxray-db/segbits_int_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com) | 13:55 |
| litghost | Geh, true enough | 14:21 |
| sf-slack1 | <tmichalak> So maybe solving byp_alt in the same fuzzer as fan_alt might be a good idea? | 14:53 |
| *** citypw has joined #symbiflow | 15:03 | |
| sf-slack1 | <acomodi> litghost: I am about to open the PRs. Would it be better to squash the commits? (e.g. separate the `modes` check that you have been dealing with in two commits, one for the VPR change and one for the regression test) | 15:11 |
| litghost | Ya, let's squash | 15:13 |
| litghost | Same as the modes example | 15:13 |
| *** citypw has quit IRC | 15:37 | |
| litghost | tmichalak: Sure | 15:46 |
| *** OmniMancer has quit IRC | 15:49 | |
| sf-slack1 | <acomodi> litghost: I am checking whether everything works fine, in doing so and checking the branch with an isolated patch I encountered this error `calc_relaxed_criticality: Assertion 'crit >= 0. - CRITICALITY_ROUND_OFF_TOLERANCE' failed (Criticality should never be negative).` | 15:49 |
| litghost | acomodi: There is a a commit that disables this check | 15:50 |
| litghost | acomodi: I'm not totally certain, but I believe that error is due to terrible timing information | 15:50 |
| litghost | acomodi: When we have valid a timing model in VPR, I believe we can take out that commit | 15:50 |
| litghost | acomodi: Maybe we should add a flag to disable that check? | 15:50 |
| litghost | acomodi: For architecture bootstrapping purposes | 15:51 |
| sf-slack1 | <acomodi> litghost: well, another option to vpr would not be bad, it would make it more flexible | 15:51 |
| sf-slack1 | <acomodi> litghost: I will enable it temporarly just to test everything related to the patch works fine | 15:52 |
| litghost | acomodi: Sounds good | 15:52 |
| *** kgugala has joined #symbiflow | 16:31 | |
| mithro | kgugala: Can you join #vtr-dev ? | 16:45 |
| sf-slack1 | <acomodi> litghost: is this error familiar to you? `Error 1: STA Engine: IPIN has no out-going edges (Netlist Pin: '$auto$alumacc.cc:474:replace_alu$26.slice[21].top_of_carry.DI[0]', Timing Graph Node: 192)` | 16:47 |
| litghost | acomodi: Yes | 16:48 |
| litghost | acomodi: That is an error we disabled | 16:50 |
| sf-slack1 | <acomodi> litghost: all right, so it is independent w.r.t. the `modes` feature | 16:50 |
| litghost | acomodi: Believe so | 16:51 |
| sf-slack1 | <acomodi> litghost: I am pretty sure, otherwise the `routing_modes` regression test would have failed | 16:52 |
| litghost | acomodi: Agreed | 16:52 |
| kgugala | mithro: I'm thre | 17:05 |
| kgugala | *there | 17:05 |
| sf-slack1 | <acomodi> litghost, mithro: I am checking whether murax is working on HW using the VTR patch (and the minor hacks which will not be upstreamed) and I'll open the PR | 18:00 |
| litghost | acomodi: Sounds great! | 18:00 |
| sf-slack1 | <acomodi> I have included in the same patch the `slicem modes` fix in a different commit and the relative regression test in another one | 18:01 |
| sf-slack1 | <acomodi> Mainly because there was no sense in separating them in two different PRs | 18:01 |
| sf-slack1 | <acomodi> litghost: so, unfortunately I will exclude the fix for the slicem modes that I have been dealing with as the `slicem.xml` test architecture file implies the usage of some workarounds. I will try to modify the test architecture so not to rely on the workarounds | 18:29 |
| litghost | acomodi: Sounds good | 18:30 |
| sf-slack1 | <acomodi> litghost, mithro: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517 here it is | 18:48 |
| tpb | Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 18:49 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!