space_zealot has joined #symbiflow
space_zealot has quit [Ping timeout: 248 seconds]
space_zealot has joined #symbiflow
futarisIRCcloud has joined #symbiflow
_whitelogger has joined #symbiflow
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 244 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
proteusguy has joined #symbiflow
OmniMancer has joined #symbiflow
proteusguy has quit [Ping timeout: 272 seconds]
proteusguy has joined #symbiflow
proteusguy has quit [Ping timeout: 272 seconds]
Bertl_zZ is now known as Bertl
space_zealot has quit [Ping timeout: 250 seconds]
proteusguy has joined #symbiflow
bjorkintosh has joined #symbiflow
adjtm_ has joined #symbiflow
adjtm has quit [Ping timeout: 248 seconds]
<sf-slack2> <mkurc> @mithro @litghost I summarized my thoughts for modeling async set/reset FFs with timing in VPR in a document: https://docs.google.com/document/d/1fJeQzc3nGYEQM71kpeHHexxblx6I7CdrhAtjnZRtZXc
<tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)
proteusguy has quit [Ping timeout: 248 seconds]
OmniMancer has quit [Quit: Leaving.]
proteusguy has joined #symbiflow
<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?
<litghost> kgugala: The current XML structure is logically valid, but may not be suitable to the timing model
<sf-slack2> <kgugala> @litghost I'm talking about what I got from 007 fuzzer
<litghost> kgugala: I think the values you have are correct
<sf-slack2> <kgugala> so every LUT6 delay looks the same:
<litghost> LUT6 I* -> O6 is all the same
<sf-slack2> <kgugala> (IOPATH A1 O6 (0.045::0.056)(0.1::0.124))
<litghost> Ya
<sf-slack2> <kgugala> that is why I think this is not whole path delay, but rather MUX6 one
<sf-slack2> <kgugala> otherwise they'd probably differ
<sf-slack2> <kgugala> like in LUT5
<litghost> You can always make some example designs and check the path timing in vivado if you think our understand is incorrect
<litghost> However given that I've seen good critical path analysis out of VPR, I think our numbers are right
<sf-slack2> <kgugala> right now we do not define any delay for F6MUX in LUT6
<sf-slack2> <kgugala> we have only LUT5 delays
<litghost> So the F6MUX is not "real" in the SDF sense
<litghost> The O6 delays are from the LUT6_2 inputs to the O6 output
<sf-slack2> <kgugala> yep
<litghost> And the O5 delays from the LUT6_2 inputs to the O5 output (minus I6)
<sf-slack2> <kgugala> correct
<litghost> Structurely the F6MUX is part of the combitorial path of inputs to O6
<sf-slack2> <kgugala> yes
<litghost> We need to decompose the O5 and O6 delays to accomidate how we are modeling things
<litghost> Because O6 delays are fixed, that could be models as a single delay on the direct connect from the O6 to reset of SLICE
<litghost> O5 is more complicated, haven't figured out how to handle it
<sf-slack2> <kgugala> I'd assume that O6 delays should be bigger than O5
<litghost> Not nessecarily
<litghost> Keep in mind that logical models and timing models don't have to overlap
<litghost> The actually hardware implementation may be different to allow for better timing
<litghost> For example, the CARRY4 timing indicates an interesting structure on the CIN fanout
<litghost> One that isn't intuitive, and doesn't match the logic design
<litghost> This is not really that suprising
<sf-slack2> <kgugala> makes sense
<mithro> mkurc: Please work with the upstream VtR devs to fix the async set/reset problem rather than work around it.
<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.
<mithro> kgugala: So, some of the fuzzers are still disabled in master prjxray
<sf-slack2> <kgugala> @mithro I see 41, 57 and 71 and 41 because it runs too long
<sf-slack2> <kgugala> @mithro does that prevent new timing DB generation?
<mithro> kgugala: Means I have to do manual fix ups which are prone with error
<sf-slack2> <kgugala> I understand
<sf-slack2> <kgugala> so maybe we can wait with this?
<sf-slack2> <kgugala> @mithro I found a bug preventing BRAMS timings to be emited
<sf-slack2> <kgugala> @mithro also there is https://github.com/SymbiFlow/prjxray/pull/857 not yet merged
<tpb> Title: Fixed fuzzer 007 to make it extract missing timings for FFs by mkurc-ant · Pull Request #857 · SymbiFlow/prjxray · GitHub (at github.com)
<sf-slack2> <tmichalak> Actually only 41 and 57 are disabled, 71 has just different dependencies because normally depends on 57 which has been disabled
<mithro> kgugala: Okay, I've pushed an updated database till "Merge pull request #842 from antmicro/bits_origin"
<hackerfoo> litghost: 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.
<litghost> hackerfoo: Odd
<sf-slack2> <kgugala> @mithro thanks
<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?
<litghost> kgugala: Update it your PR
<sf-slack2> <kgugala> ok
<litghost> kgugala: If you find that other errors crop up as a result, it might be worth splitting it into two PRs
<litghost> kgugala: But first shot should be update at same time
<sf-slack2> <kgugala> @litghost they do not trigger any errors in this PR - I noticed missing BRAM timings when started working on adding them there
<sf-slack2> <kgugala> @litghost we can land this PR and than I'll open a new one with missing timings
<sf-slack2> <kgugala> @litghost this way it will be easier to review them
<litghost> kgugala: Yes
<sf-slack2> <kgugala> @litghost @elms @mithro I have rabased the PR, bumped the db submodule and pushed it. Please take a look https://github.com/SymbiFlow/symbiflow-arch-defs/pull/738
<tpb> Title: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> Hopefully CI goes green
<mithro> litghost / kgugala: Do the prjxray-db changes look good?
<tpb> Title: build(deps): bump third_party/prjxray-db from `34ea6eb` to `692e9b3` by dependabot-preview · Pull Request #799 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<sf-slack2> <kgugala> @mithro sdf changes look good
<litghost> mithro: Some of the bipip's are missing segbits now
<tpb> Title: Comparing 34ea6eb08a63d21ec16264ad37a0a7b142ff6031...692e9b3d9717710110204798cb18dc8fcb243fe4 · SymbiFlow/prjxray-db · GitHub (at github.com)
<litghost> It looks like only zynq segbits are affected, which is interesting
<litghost> zynq also lost some bits in the LIOB file
<sf-slack2> <kgugala> hmm, should there be LIOB db for zynq?
<sf-slack2> <kgugala> the zynqs we support do not have left IOs
<sf-slack2> <kgugala> @litghost the timing PR is green :slightly_smiling_face:
<litghost> kgugala: Which one?
<tpb> Title: Arch XML timings by kgugala · Pull Request #738 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> Ah, yes
futarisIRCcloud has joined #symbiflow
Xark has quit [Ping timeout: 246 seconds]
Bertl is now known as Bertl_zZ
_whitelogger has joined #symbiflow
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow
_whitelogger has joined #symbiflow