proteusguy has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<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?
<tpb>
Title: INT FAN_ALT[0-9].GFAN0 solutions are still unstable · Issue #567 · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack1>
<tmichalak> So maybe solving byp_alt in the same fuzzer as fan_alt might be a good idea?
citypw has joined #symbiflow
<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)
<litghost>
Ya, let's squash
<litghost>
Same as the modes example
citypw has quit [Ping timeout: 272 seconds]
<litghost>
tmichalak: Sure
OmniMancer has quit [Quit: Leaving.]
<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).`
<litghost>
acomodi: There is a a commit that disables this check
<litghost>
acomodi: I'm not totally certain, but I believe that error is due to terrible timing information
<litghost>
acomodi: When we have valid a timing model in VPR, I believe we can take out that commit
<litghost>
acomodi: Maybe we should add a flag to disable that check?
<litghost>
acomodi: For architecture bootstrapping purposes
<sf-slack1>
<acomodi> litghost: well, another option to vpr would not be bad, it would make it more flexible
<sf-slack1>
<acomodi> litghost: I will enable it temporarly just to test everything related to the patch works fine
<litghost>
acomodi: Sounds good
kgugala has joined #symbiflow
<mithro>
kgugala: Can you join #vtr-dev ?
<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)`
<litghost>
acomodi: Yes
<litghost>
acomodi: That is an error we disabled
<sf-slack1>
<acomodi> litghost: all right, so it is independent w.r.t. the `modes` feature
<litghost>
acomodi: Believe so
<sf-slack1>
<acomodi> litghost: I am pretty sure, otherwise the `routing_modes` regression test would have failed
<litghost>
acomodi: Agreed
<kgugala>
mithro: I'm thre
<kgugala>
*there
<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
<litghost>
acomodi: Sounds great!
<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
<sf-slack1>
<acomodi> Mainly because there was no sense in separating them in two different PRs
<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