14:50 <sf-slack2> <acomodi> I think I finally found a way to let the mode selection work without increasing the original pack time.

14:50 <sf-slack2> <acomodi> Basically now different mode selection is activated only when there is no possible route while expanding nodes in `try_intra_lb_route`

15:16 <sf-slack2> <mkurc> Good time of day!

15:16 <sf-slack2> <mkurc> @mitrho I started merging my code related to FASM support in V2X

15:17 <sf-slack2> <mkurc> @mithro It seems that the V2X no longer groups instances of the same module into one pb_type

15:17 <sf-slack2> <mkurc> @mithro For example, for the following verilog input:

15:18 <sf-slack2> <mkurc> @mithro https://pastebin.com/sVAHNCDY

15:18 <tpb> Title: [VeriLog] `include "../common/and_gate/and_gate.sim.v" `include "../common/xor_gate/xor_g - Pastebin.com (at pastebin.com)

15:18 <sf-slack2> <mkurc> @mithro I have:

15:18 <sf-slack2> <mkurc> @mitrho: https://pastebin.com/sEZGk8vQ

15:18 <tpb> Title: [XML] (at pastebin.com)

15:19 <sf-slack2> <mkurc> @mithro Those four gates are of the same type and should be grouped into one <pb_type> tag with num_pb = 4

17:04 <mithro> litghost: I like the idea behind https://github.com/SymbiFlow/prjxray/pull/842 -- could you check the implementation....

17:04 <tpb> Title: Generate db files with fuzzer name of origin by tmichalak · Pull Request #842 · SymbiFlow/prjxray · GitHub (at github.com)

17:55 <litghost> acomodi: Sounds good, do you have data to support the increased performance?

17:58 <sf-slack2> <acomodi> litghost: I am running again the VTR benchmarks, they should complete in about an hour. I have checked the run-time difference on a test that took ~10% more than master and now it takes almost the same time

17:58 <litghost> acomodi: That's a promising sign

18:05 <sf-slack2> <acomodi> litghost: Yes, I think this is the best we can get, once the first batch completes I'll run the Titan benchmarks. I believe after I get those the PR will get merged.

18:06 <litghost> acomodi: Great

18:43 <sf-slack2> <acomodi> litghost: packing time is even less now w.r.t master. The whole VTR flow still takes ~0.8% time more w.r.t. master. If interested the comparison is here: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issuecomment-494104583

18:43 <tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

22:46 <mithro> @acomodi: I don't quite understand your qor stuff on #517?

22:46 <mithro> @acomodi: It seems like packing time has gone up by either 4-5% or 10%? which is it?

22:54 <sf-slack2> <acomodi> mithro: that was before the changes I have committed today. Right now we have a no increase in packing time.

22:54 <mithro> acomodi: So?

22:55 <mithro> acomodi: Can you mention in that patch what the change is rather than just uploading the xls file?

22:55 <mithro> Vaughn's latest comment was "The +10% pack time is a pain, but otherwise everthing looks good. "

22:57 <sf-slack2> <acomodi> mithro: Sure, I'll update the comment

23:03 <sf-slack2> <acomodi> mithro: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issuecomment-494104583

23:03 <tpb> Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)