11:48 <sf-slack1> <mkurc> I have a question regarding 7-series CLB architecture: There is an interconnect in each CLB through which two SLICEs are connected to a "Center" interconnect (that is how Vivado calls it). I've also found pip definitions for it in the CLB tile-type JSON file.

11:48 <sf-slack1> <mkurc> But are these pips actually there? I couldn't find any bits related to them and the CLB interconnect provides only 1:1 connections between each slice and the "center" interconnect.

11:49 <sf-slack1> <mkurc> Also couldn't find any evidence that these pips are somehow relevant for the VPR.

11:50 <sf-slack1> <mkurc> So can I treat the interconnect within a CLB as transparent and skip it completely when defining an universal eg. SLICEL tile ?

11:51 <sf-slack1> <acomodi> @mkurc They most probably are `ppips` if they have 1:1 connections

11:52 <sf-slack1> <mkurc> hmmm

11:53 <sf-slack1> <mkurc> eg. in `tile_type_CLBLL_L.json` there is a filled in section called `pips`. But I couldn't find any piece of code that refers to that section for importing its data to the VPR

11:55 <sf-slack1> <mkurc> If so, then the VPR does not care about these pips. And I couldn't find any bits related to them in the database.

11:57 <sf-slack1> <acomodi> yep, but those ppips have to be present in the db, otherwise there will be an error in the `frames` step of symbiflow. I think VPR needs to know only that there is a connection there (CLB --> Center_INT)

11:58 <sf-slack1> <mkurc> Agree, CLB -> Center_INT. But not SLICE_X0Y0 -> CLB pins and SLICE_X1Y0 -> CLB pins.

12:05 <sf-slack1> <acomodi> What you mean by "But not SLICE_X0Y0 -> CLB pins and SLICE_X1Y0 -> CLB pins"?

12:05 <sf-slack1> <mkurc> Meaning that there are pips inside a CLB that define connections between SLICEs and outgoing tile pins.

12:11 <sf-slack1> <acomodi> Yes, and I believe that all of these pips are actually `ppips` and have no bits

12:11 <sf-slack1> <mkurc> Ok, thanks

16:36 <litghost> mkurc: Those pips are used for routing import here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_create_edges.py#L834

16:36 <tpb> Title: symbiflow-arch-defs/prjxray_create_edges.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

16:37 <litghost> mkurc: acomodi's analysis is that those pips are all 1:1, and so are ppips (e.g. no configuration), however those pips relate the site pin wires to the CLBLx_x wires that connect to the interconnect per tile conn

17:08 <mithro> Just FYI - I've updated the dependabot for prjxray to only send pull requests once a week

17:31 <sf-slack1> <mkurc> @litghost: Thanks. So if there is no pip between a site pin and a tile wire within a tile then no connection will be formed ?

17:33 <litghost> mkurc: pips are always between tile wires, so your question is ill-formed. Can you rephrase?

17:37 <sf-slack1> <mkurc> @lighost: In a tile definition file (eg `tile_type_CLBLL.json`) there is a section "wires" which holds all wires within that tile. Then, there is a "sites" section which holds site information. And then each site has its section named "site_pins" which defines which pin of the site is connected to which wire within the tile.

17:37 <sf-slack1> <mkurc> And there is also a section "pips" which define pips.

17:38 <sf-slack1> <mkurc> And connections defined within the whole structure are like that: site_pin -> site_wire -> pip -> tile_wire.

17:39 <sf-slack1> <mkurc> And my question is when the name of site_wire is equal to name of tile_wire (no pip) is it considered as a connection ?

17:49 <litghost> mkurc: Incorrect

17:49 <litghost> mkurc: site_pin -> tile_wire -> pip ...

17:50 <litghost> mkurc: site_wire's only exist within a site

17:50 <sf-slack1> <mkurc> Ahhh, now I see.

17:51 <litghost> mkurc: I've sent https://docs.google.com/document/d/1iElkfCf9jiE5QiQYh5RAXVrjHU9t2n4M_xiSh5m5BaI/edit to you, but here it is again

17:51 <tpb> Title: Google Docs - create and edit documents online, for free. (at docs.google.com)

17:52 <sf-slack1> <mkurc> @litghost: I see it has been updated. Thanks.

17:52 <litghost> mkurc: Nothing has materially changed

17:53 <litghost> mkurc: Some diagrams were added, but the original contents were correct

17:54 <sf-slack1> <mkurc> Yes, it was. But the diagrams make it easier to understand some nuances.

19:00 <sf-slack1> <acomodi> litghost: how do we proceed with the VTR patches isolation?

19:00 <litghost> acomodi: Not sure what you mean? Can you not create PR's for the items you've identified?

19:11 <sf-slack1> <acomodi> litghost: Ok, I'll proceed with opening all the different PRs upstream after having double checked that they are independent. The eblif related ones are correct in the docs or there are some items missing?

19:26 <litghost> acomodi: eblif is a non-standard blif extension, so extended support is something we've been working on. I believe there is some documentation in yosys, but we probably need to add something to VPR too. I believe that VPR might already have upstream eblif read support, those commits were adding eblif write support? Double check

21:17 <mithro> litghost: Did you find https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/365

21:17 <tpb> Title: Support packing when modes provide different routing by mithro · Pull Request #365 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com)

21:17 <mithro> litghost: It has a test example of the routing modes stuff

21:17 <litghost> mithro: I believe so, but I'm taking a different approach initially

21:25 <mithro> litghost: Okay

22:08 <mithro> litghost: This is what we currently say -> https://summerofcode.withgoogle.com/organizations/4517422304854016/

22:09 <mithro> litghost: Our GSoC page is at https://symbiflow.github.io/summer-of-code

22:09 <tpb> Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io)