*** tpb has joined #vtr-dev | 00:00 | |
mithro | litghost: https://github.com/verilog-to-routing/vtr-verilog-to-routing/compare/c_internal | 05:29 |
---|---|---|
tpb | Title: Comparing master...c_internal · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 05:29 |
acomodi | kem_: a question about `t_type_descriptor`: shouldn't the indices be `StrongId`instead of plain `int`? https://github.com/verilog-to-routing/vtr-verilog-to-routing/blob/f6d5c7e2857f0aaa412a0d8165a41312c17ebcb6/libs/libarchfpga/src/physical_types.h#L583 | 11:31 |
tpb | Title: vtr-verilog-to-routing/physical_types.h at f6d5c7e2857f0aaa412a0d8165a41312c17ebcb6 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 11:31 |
kem_ | acomodi: VPR has historically used plain int as indicies/handles | 14:50 |
kem_ | acomodi: We've been slowly transitioning various data structures to use StrongId's instead | 14:50 |
kem_ | acomodi: Which give better error checking (compilation errors if you pass the wrong type of ID, instead of silent acceptance) | 14:52 |
kem_ | acomodi: However no one's transitioned the type descriptors to use StrongIds yet | 14:52 |
acomodi | kem_: all right, I am about to open a PR with an initial working change to address the equivalent tiles feature. Probably, alongside with this change, if it does not require too much effort, I could also start transitioning to the usage of StrongId also for type descriptors | 15:09 |
acomodi | kem_, litghost, mithro: the Equivalent Tile PR is now available here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/559 | 15:30 |
tpb | Title: WIP [DNM]: Equivalent Tiles placement by acomodi · Pull Request #559 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 15:30 |
litghost | acomodi: Can you look into https://github.com/SymbiFlow/symbiflow-arch-defs/pull/700#issuecomment-490534729 ? | 15:44 |
tpb | Title: [WIP]: Update VTR with upstream patches. by litghost · Pull Request #700 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:44 |
acomodi | litghost: sure, kem_ any ideas on what are the possible causes of an infinite routing? overused RR nodes get down to 1-10 and VPR cannot get to a feasible solution. | 15:47 |
acomodi | kem_: ^ | 15:48 |
litghost | acomodi: I found that the high fanout stuff caused it on xc7, and disabled it | 15:48 |
litghost | acomodi: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/common/cmake/devices.cmake#L553 | 15:49 |
tpb | Title: symbiflow-arch-defs/devices.cmake at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 15:49 |
acomodi | litghost: ok, I'll try to disable that as well for ice40 and run it locally to see if that solves it | 15:49 |
litghost | acomodi: However it is disabled on all arches for us | 15:49 |
litghost | acomodi: I used a git bisect last time this happened | 15:49 |
litghost | acomodi: Probably the right solution here too | 15:49 |
kem_ | acomodi: When you hit congestion which doesn't resolve that can be tough to debug | 15:50 |
kem_ | acomodi: Its not always obvious whether it is an algorithm issue or more fundamental to the design | 15:51 |
litghost | kem_: The only thing that changed was VTR | 15:52 |
kem_ | acomodi: Some optimizations like high fanout routing do restrict the router search space to save CPU time, so it is possible it could cause issues as litghost mentioned. | 15:52 |
litghost | kem_: The input eblif and arch.xml and rrgraph remained the same | 15:52 |
kem_ | litghost: What was changed in VPR then? | 15:53 |
litghost | kem_: We merged upstream into our fork | 15:53 |
litghost | kem_: So "a lot" | 15:53 |
kem_ | litghost: OK | 15:53 |
litghost | https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/49 | 15:53 |
tpb | Title: Merge upstream by acomodi · Pull Request #49 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 15:53 |
kem_ | litghost: Thats a tough one to debug | 15:54 |
litghost | Ya, this is a case where bisect is the right answer | 15:54 |
litghost | That's what I did last time we hit this | 15:54 |
acomodi | kem_, litghost: I will go on and use git bisect and try to get where the issue is | 15:54 |
kem_ | litghost: Makes sense | 15:55 |
litghost | acomodi: Once we've identified the issue, it is probably worth reducing to a test case and pushing upstream | 15:55 |
kem_ | litghost: I guess my point is that the thing that fails in the bisect may or may not be the fundamental issue | 15:55 |
litghost | kem_: Of course. Step 1 is identifying proximate cause, what change induced the symptom | 15:56 |
kem_ | litghost: Yep agreed | 15:56 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!