Tuesday, 2019-03-26

*** tpb has joined #symbiflow00:00
*** futarisIRCcloud has joined #symbiflow00:31
*** citypw has joined #symbiflow03:23
mithrokgugala: ping?03:58
*** proteusguy has joined #symbiflow05:03
sf-slack1<kgugala> mithro: I'm here05:16
*** Bertl_oO is now known as Bertl_zZ06:03
*** proteusguy has quit IRC07:57
*** kraiskil has joined #symbiflow08:08
*** proteusguy has joined #symbiflow08:09
*** kraiskil has quit IRC08:47
*** OmniMancer has joined #symbiflow09:09
*** citypw has quit IRC09:48
*** Bertl_zZ is now known as Bertl10:40
*** proteusguy has quit IRC10:59
*** futarisIRCcloud has quit IRC13: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
tpbTitle: 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
tpbTitle: prjxray-db/segbits_int_l.db at master · SymbiFlow/prjxray-db · GitHub (at github.com)13:55
litghostGeh, true enough14: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 #symbiflow15: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
litghostYa, let's squash15:13
litghostSame as the modes example15:13
*** citypw has quit IRC15:37
litghosttmichalak: Sure15:46
*** OmniMancer has quit IRC15: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
litghostacomodi: There is a a commit that disables this check15:50
litghostacomodi: I'm not totally certain, but I believe that error is due to terrible timing information15:50
litghostacomodi: When we have valid a timing model in VPR, I believe we can take out that commit15:50
litghostacomodi: Maybe we should add a flag to disable that check?15:50
litghostacomodi: For architecture bootstrapping purposes15:51
sf-slack1<acomodi> litghost: well, another option to vpr would not be bad, it would make it more flexible15:51
sf-slack1<acomodi> litghost: I will enable it temporarly just to test everything related to the patch works fine15:52
litghostacomodi: Sounds good15:52
*** kgugala has joined #symbiflow16:31
mithrokgugala: 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
litghostacomodi: Yes16:48
litghostacomodi: That is an error we disabled16:50
sf-slack1<acomodi> litghost: all right, so it is independent w.r.t. the `modes`  feature16:50
litghostacomodi: Believe so16:51
sf-slack1<acomodi> litghost: I am pretty sure, otherwise the `routing_modes` regression test would have failed16:52
litghostacomodi: Agreed16:52
kgugalamithro: I'm thre17:05
kgugala*there17: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 PR18:00
litghostacomodi: 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 one18:01
sf-slack1<acomodi> Mainly because there was no sense in separating them in two different PRs18: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 workarounds18:29
litghostacomodi: Sounds good18:30
sf-slack1<acomodi> litghost, mithro: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517 here it is18:48
tpbTitle: 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!