futarisIRCcloud has joined #symbiflow
citypw has joined #symbiflow
jevinski_ has joined #symbiflow
jevinskie has quit [Ping timeout: 258 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
proteusguy has joined #symbiflow
OmniMancer has joined #symbiflow
Bertl_zZ is now known as Bertl
celadon_ has joined #symbiflow
celadon has quit [Ping timeout: 255 seconds]
vup2 is now known as vup
proteusguy has quit [Remote host closed the connection]
Vonter has quit [Ping timeout: 252 seconds]
Vonter has joined #symbiflow
felix___ is now known as felix_
proteusguy has joined #symbiflow
acomodi has quit [Ping timeout: 252 seconds]
acomodi has joined #symbiflow
Bertl has quit [Ping timeout: 246 seconds]
Bertl has joined #symbiflow
<sf-slack2> <acomodi> litghost, mithro: I have opened a PR to change the VTR mode selection mechanism in symbiflow (https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/50) and I have also updated the current PR in VTR mainline as well (https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517)
<tpb> Title: mode selection: check modes while committing rt nets by acomodi · Pull Request #50 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)
<sf-slack2> <acomodi> litghost, mithro: I am running the titan benchmarks to get to see how better the new solution is w.r.t. the backtraced check of `Differing modes`
<sf-slack2> <acomodi> I had troubles with running picosoc on HW using https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/559, but it turns out to be a timing issue, by adding an additional timing divider it now works
<sf-slack2> <acomodi> *clock divider
<elms> tiempo of day dobry
OmniMancer has quit [Quit: Leaving.]
kgugala has quit [Quit: WeeChat 1.9.1]
<mithro> mkurc / kgugala: Morning?
<mithro> Morning everyone...
<sf-slack2> <mgielda> morning!
<mithro> mkurc: I think your FASM attribute stuff is potentially workable but we need to land https://github.com/SymbiFlow/symbiflow-arch-defs/pull/703 first I think?
<tpb> Title: mux_gen + v2x: Support generating FASM annotations for muxes. by mithro · Pull Request #703 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
citypw has quit [Ping timeout: 258 seconds]
<mithro> Meeting now, if your around afterwards I would like to sync up on the status of it
<sf-slack2> <kgugala> @mithro: morning
karol_ has joined #symbiflow
karol_ is now known as kgugals
kgugals is now known as kgugala
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<duck2> morning
Jon_ has joined #symbiflow
<sf-slack2> <mkurc> Morning!
<sf-slack2> <mkurc> @mithro Changes to muxgen and v2x are somewhat independent. I still need to make final fixes to make generated xmls pass the recently merged vpr test.
<mithro> mkurc: I did a pretty major refactor ot v2x to support the FASM values for muxgen output
<sf-slack2> <mkurc> @mithro I see now that I still have some unresolved issues in discussion with @litghost about my implementation of the v2x FASM support. I hope I'll be able to resolve all that by tomorrow.
<mithro> mkurc: I think for now it might be a good idea to stop work on it until I can resolve conflicts with my pull request and yours
<sf-slack2> <mkurc> @mithro Yep. But I see that my changes to the v2x are not so extensive. It might be easier to merge mine to yours.
<mithro> mkurc: Yes, I'll will do that
<mithro> mkurc: I want to get the pack pattern stuff working first
<sf-slack2> <mkurc> @mithro Ok.
<mithro> mkurc: Could you maybe look at finishing off https://github.com/SymbiFlow/symbiflow-arch-defs/pull/645/files ?
<tpb> Title: WIP - utils/vlog: More tests from timing tutorial. by mithro · Pull Request #645 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<mithro> mkurc: Looks like most of the stuff needed for that is filling out the documentation and figuring out why the test fails?
<sf-slack2> <mkurc> @mithro Ok, I can look into that.
alexhw has quit [Remote host closed the connection]
Bertl is now known as Bertl_oO
_whitelogger_ has joined #symbiflow
<mithro> litghost: So, I'm just looking at pack-pattern generation at the moment
<mithro> litghost: Were are the most complicated pack-patterns in the xc7 target?
<litghost> mithro: I don't know if its the most complicated, but I'd start with the CE VCC and SR GND pack patterns
<litghost> mithro: They are awful when written by hand, and I would love to move them to something better
<litghost> mithro: Most of the other pack patterns aren't too bad
<tpb> Title: symbiflow-arch-defs/common_slice.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> mithro: Ideally the pack pattern would be generated inside of a generate statement
<litghost> mithro: I was thinking as wire attributes, but I haven't really looked into it
<tpb> Title: symbiflow-arch-defs/ff.pb_type.xml at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
<litghost> mithro: Yep
<litghost> mithro: Ideally we could annotate the sink and source of the pack pattern, and annotate the in between
<litghost> mithro: But I'm open to other suggestions
<mithro> litghost: This pack pattern starts on the SR_GND output and ends on the Flip-Flop S input?
<litghost> mithro: Or CE_VCC and ends at CE
<litghost> mithro: Yes
<mithro> litghost: And there are multiple ones because of the multiple modes that the FF can be in?
<litghost> mithro: There are 3 patterns per FF type, CE=VCC, SR=GND, and CE=VCC+SR=GND
<litghost> mithro: Two dimensions, FF blackbox type (e.g. FDRE vs FDSE) and pack combination (CE=VCC / SR=GND / CE=VCC+SR=GND)
<litghost> mithro: That last one (CE=VCC+SR=GND), it is unclear if that patterns is actually required, or whether the component parts are sufficient
<mithro> litghost: Probably as things can only be part of one pack-pattern...
<mithro> Be back in 30mins, meeting
<litghost> mithro: Okay, good luck
<mithro> litghost: There was something like "specialize carry chains" or similar somewhere?
<litghost> mithro: Still is
<litghost> mithro: I wanted to wait until we had timing results in to determine course of action on the specialization
<mithro> litghost: Ahh, it's not xc7 specific, its in utils/specialize_carrychains.py
<mithro> litghost: What does it do?
<litghost> mithro: Ensures carry chain names are unique based on their parentage
<litghost> mithro: So the SLICEM carry chain has a different pattern than the SLICEL carry chain
<litghost> mithro: It is unclear that we actually want the carry chain in SLICEM to be used over the SLICEL, except when LUT-RAM's or SRL are required
<litghost> mithro: Equiv tiles enable putting a SLICEL cluster at a SLICEM tile so we are limiting our resources
proteusguy has quit [Ping timeout: 246 seconds]
<mithro> Does anyone need me to review anything?
proteusguy has joined #symbiflow
<litghost> elms requested a second reviewer on https://github.com/SymbiFlow/symbiflow-arch-defs/pull/708
<tpb> Title: Initial xc7 route timing import. by litghost · Pull Request #708 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)
_whitelogger has joined #symbiflow
tpb has quit [Remote host closed the connection]
tpb has joined #symbiflow