14:41 <sf-slack3> <mkurc> @litghost: Regarding the ROI breakout, I think that the next logical thing to do is to modify prjxray import scripts so they can do something like tile merge+split (or split+merge).

14:42 <sf-slack3> <mkurc> @litghost Could you provide some insights how do you see that implemented? From what I understand effectively we need some sites from IOI3 and IOB33 to end up together in the new tile type IOPAD. And we (probably) need different IOPAD tile type for *M and *S IOB sites.

15:29 <litghost> hackerfoo has already done some of this. I believe your second sentence is right, there should be iopadm, iopads, and iopad_sing. Each should accept an IOPAD logical site, and the m/s tiles should accept the IOPADM and Iopads logical sites respectively

16:58 <hackerfoo> mkurc: Merging IOI3+IOB33 into an IOPAD tile is already implemented.

16:59 <hackerfoo> But for routing, only IOI3 is considered, since IOBs are (mostly) not routed, and connect to an adjacent IOI3.

17:00 <hackerfoo> The vertical splitting is implemented as a filter (SELECT_Y) on tile import.

17:01 <hackerfoo> So IOPAD_M will have SELECT_Y 1, and IOPAD_S will have SELECT_Y 0, and IOPAD_SING doesn't need a filter.

17:05 <hackerfoo> The filter also needs to be applied to the ports in the IOPAD tile (e.g. n = SELECT_Y in IOI_OLOGIG<n>_* ), which is not being done yet.

19:16 <sf-slack3> <mkurc> @hackerfoo: But won't filtering sites using SELECT_Y break routing? There is only one IOI3 considered by the routing import scripts and you want to effectively import it to the VPR twice and place them at differing grid coordinates. The VPR grid is generated by the prjxray_arch_import.py. Information about existence of IOPAD_M and IOPAD_S isn't there.

20:20 <hackerfoo> mkurc: I talked to litghost and it sounds like the tile_splitter should work as-is, but we need to modify the scripts to insert IOPAD_S' below IOPAD_M's (currently IOPAD) and to associate the correct wires with each.

20:34 <litghost> acomodi: Now that tile/pb_type split is in place in upstream VTR, are you planning on integrating that change into VTR and updating symbiflow to do the right thing?

20:35 <litghost> acomodi: In the short term should we just emit the old style arch.xml and use the conversion script?

20:56 <sf-slack3> <acomodi> litghost: Yeah, I think we should update VPR to the upstream version, and IMO it would be good to update symbiflow to adapt it to the new format, without using the conversion script. It shouldn't require too much effort, it will be a matter of changing the `prjxray_tile_import` script accordingly. The only problem could be ice40, as I am not familiar on the architecture generation.

21:04 <litghost> For ice40 and testarch just use the conversion script

21:09 <sf-slack3> <acomodi> Sounds good

22:28 <hackerfoo> https://siliconpr0n.org/map/xilinx/xc7a35t/mz_mit20x/

22:28 <tpb> Title: Loading... (at siliconpr0n.org)