Thursday, 2019-05-30

*** tpb has joined #symbiflow00:00
*** space_zealot has joined #symbiflow00:42
*** space_zealot has quit IRC01:28
*** space_zealot has joined #symbiflow01:47
*** futarisIRCcloud has joined #symbiflow03:39
*** _whitelogger has quit IRC04:11
*** _whitelogger has joined #symbiflow04:14
*** proteusguy has joined #symbiflow05:18
*** proteusguy has quit IRC05:51
*** futarisIRCcloud has quit IRC06:05
*** proteusguy has joined #symbiflow06:20
*** OmniMancer has joined #symbiflow07:22
*** proteusguy has quit IRC07:44
*** proteusguy has joined #symbiflow07:56
*** proteusguy has quit IRC09:55
*** Bertl_zZ is now known as Bertl10:13
*** space_zealot has quit IRC12:13
*** proteusguy has joined #symbiflow12:19
*** bjorkintosh has joined #symbiflow12:36
*** adjtm_ has joined #symbiflow13:12
*** adjtm has quit IRC13:14
sf-slack2<mkurc> @mithro @litghost I summarized my thoughts for modeling async set/reset FFs with timing in VPR in a document:
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** proteusguy has quit IRC15:31
*** OmniMancer has quit IRC16:40
*** proteusguy has joined #symbiflow16:55
sf-slack2<kgugala> @litghost I'm looking at the LUT5/6 delays and LUT6 are smaller than LUT5. This is weird because LUT6 is made from two LUT5 and a mux. Also LUT6 delays are equal for every Ix -> O6 path. Could it be that those are not the whole path timings, but rather the mux merging two LUT5 into one LUT6?17:08
litghostkgugala: The current XML structure is logically valid, but may not be suitable to the timing model17:09
sf-slack2<kgugala> @litghost I'm talking about what I got from 007 fuzzer17:09
litghostkgugala: I think the values you have are correct17:10
sf-slack2<kgugala> so every LUT6 delay looks the same:17:10
litghostLUT6 I* -> O6 is all the same17:10
sf-slack2<kgugala> (IOPATH A1 O6 (0.045::0.056)(0.1::0.124))17:10
sf-slack2<kgugala> that is why I think this is not whole path delay, but rather MUX6 one17:11
sf-slack2<kgugala> otherwise they'd probably differ17:11
sf-slack2<kgugala> like in LUT517:11
litghostYou can always make some example designs and check the path timing in vivado if you think our understand is incorrect17:12
litghostHowever given that I've seen good critical path analysis out of VPR, I think our numbers are right17:13
sf-slack2<kgugala> right now we do not define any delay for F6MUX in LUT617:15
sf-slack2<kgugala> we have only LUT5 delays17:15
litghostSo the F6MUX is not "real" in the SDF sense17:16
litghostThe O6 delays are from the LUT6_2 inputs to the O6 output17:16
sf-slack2<kgugala> yep17:16
litghostAnd the O5 delays from the LUT6_2 inputs to the O5 output (minus I6)17:16
sf-slack2<kgugala> correct17:17
litghostStructurely the F6MUX is part of the combitorial path of inputs to O617:17
sf-slack2<kgugala> yes17:17
litghostWe need to decompose the O5 and O6 delays to accomidate how we are modeling things17:17
litghostBecause O6 delays are fixed, that could be models as a single delay on the direct connect from the O6 to reset of SLICE17:18
litghostO5 is more complicated, haven't figured out how to handle it17:18
sf-slack2<kgugala> I'd assume that O6 delays should be bigger than O517:18
litghostNot nessecarily17:18
litghostKeep in mind that logical models and timing models don't have to overlap17:19
litghostThe actually hardware implementation may be different to allow for better timing17:20
litghostFor example, the CARRY4 timing indicates an interesting structure on the CIN fanout17:20
litghostOne that isn't intuitive, and doesn't match the logic design17:20
litghostThis is not really that suprising17:21
sf-slack2<kgugala> makes sense17:29
mithromkurc: Please work with the upstream VtR devs to fix the async set/reset problem rather than work around it.17:58
sf-slack2<mkurc> @mithro Yes, I will. I just wanted to share my thoughts regarding FFs to be sure that I didn't miss something.18:01
mithrokgugala: So, some of the fuzzers are still disabled in master prjxray18:04
sf-slack2<kgugala> @mithro I see 41, 57 and 71 and 41 because it runs too long18:44
sf-slack2<kgugala> @mithro does that prevent new timing DB generation?18:45
mithrokgugala: Means I have to do manual fix ups which are prone with error18:52
sf-slack2<kgugala> I understand18:53
sf-slack2<kgugala> so maybe we can wait with this?18:53
sf-slack2<kgugala> @mithro I found a bug preventing BRAMS timings to be emited18:53
sf-slack2<kgugala> @mithro also there is not yet merged18:54
tpbTitle: Fixed fuzzer 007 to make it extract missing timings for FFs by mkurc-ant · Pull Request #857 · SymbiFlow/prjxray · GitHub (at
sf-slack2<tmichalak> Actually only 41 and 57 are disabled, 71 has just different dependencies because normally depends on 57 which has been disabled18:56
mithrokgugala: Okay, I've pushed an updated database till "Merge pull request #842 from antmicro/bits_origin"19:20
hackerfoolitghost: I figured out Yosys was crashing due to adding 8/16/32 bit support to RAMB36E1 in brams.txt. I don't know what I did wrong yet.19:24
litghosthackerfoo: Odd19:24
sf-slack2<kgugala> @mithro thanks19:35
sf-slack2<kgugala> @mithro so we need to wait for dependabot to bump the submodules in arch-defs or shall I do it manually in the PR?19:39
litghostkgugala: Update it your PR19:39
sf-slack2<kgugala> ok19:39
litghostkgugala: If you find that other errors crop up as a result, it might be worth splitting it into two PRs19:39
litghostkgugala: But first shot should be update at same time19:40
sf-slack2<kgugala> @litghost they do not trigger any errors in this PR - I noticed missing BRAM timings when started working on adding them there19:48
sf-slack2<kgugala> @litghost we can land this PR and than I'll open a new one with missing timings19:49
sf-slack2<kgugala> @litghost this way it will be easier to review them19:49
litghostkgugala: Yes19:49
sf-slack2<kgugala> @litghost @elms @mithro I have rabased the PR, bumped the db submodule and pushed it. Please take a look
tpbTitle: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostHopefully CI goes green19:52
mithrolitghost / kgugala: Do the prjxray-db changes look good?20:55
tpbTitle: build(deps): bump third_party/prjxray-db from `34ea6eb` to `692e9b3` by dependabot-preview · Pull Request #799 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<kgugala> @mithro sdf changes look good21:05
litghostmithro: Some of the bipip's are missing segbits now21:06
tpbTitle: Comparing 34ea6eb08a63d21ec16264ad37a0a7b142ff6031...692e9b3d9717710110204798cb18dc8fcb243fe4 · SymbiFlow/prjxray-db · GitHub (at
litghostIt looks like only zynq segbits are affected, which is interesting21:08
litghostzynq also lost some bits in the LIOB file21:08
sf-slack2<kgugala> hmm, should there be LIOB db for zynq?21:10
sf-slack2<kgugala> the zynqs we support do not have left IOs21:10
sf-slack2<kgugala> @litghost the timing PR is green :slightly_smiling_face:21:17
litghostkgugala: Which one?21:18
tpbTitle: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostAh, yes21:18
*** futarisIRCcloud has joined #symbiflow21:27
*** Xark has quit IRC22:12
*** Bertl is now known as Bertl_zZ23:23
*** _whitelogger has quit IRC23:29
*** _whitelogger has joined #symbiflow23:32

Generated by 2.13.1 by Marius Gedminas - find it at!