10:57 <sf-slack> <acomodi> mithro: updated the doc

11:12 <sf-slack> <mkurc> @hackerfoo @litghost I've been looking through the ROI breakout PR #852 in a hope for finding a simple fix. I haven't find it so far.

11:14 <sf-slack> <mkurc> @hackerfoo @litghost My question is: Do we actually need to merge IOB33 and IOI3 tiles? The current prjxray db contains fasm features for both types. Once merged we won't be able to distinguish them.

11:16 <sf-slack> <mkurc> @hackerfoo @litghost In my opinion modeling IOBs and IOIs as separate tiles would greatly reduce the amount of work for ROI breakout. Unless there is something that I am not aware of.

11:16 <hackerfoo> mkurc: There isn't really any routing fabric between them, so they have to be paired one-to-one.

11:17 <hackerfoo> Mapping between the merged tile and the physical tiles is tedious, but not difficult.

11:18 <hackerfoo> It's just that it breaks a lot of assumptions.

11:18 <sf-slack> <mkurc> That's true

11:19 <sf-slack> <mkurc> But still I think they can be modeled as separate tiles with direct connections. The VPR would then have no choice to use them together.

11:20 <sf-slack> <mkurc> It is the same like with a carry chain between CLBs. They are direct connections.

11:21 <hackerfoo> VPR shouldn't really even see IOB33 tiles, since they are connected through IOI3 tiles.

11:23 <hackerfoo> At least not for routing.

11:28 <sf-slack> <mkurc> There's still issue with fasm prefixes. A single tile in VPR can have only one. Ultimately we can rename all IO related features in the prjxray db to have identical prefixes.

14:02 <mithro> acomodi: Where did your stuff ends up?

14:02 <sf-slack> <acomodi> mithro: https://docs.google.com/document/d/11hlBnzs_1SfzWTVxWYQNDCDxRJFroodoIORaDiWbylw/edit?usp=drivesdk

14:02 <tpb> Title: SymbiFlow VtR Upstreaming Status - Google Docs (at docs.google.com)

14:36 <litghost> Another reason not to treat them separately can be approached from a choice standpoint. There is exactly one way to place say, and IOBUFDS with an ISERDES, so why allow the placer the flexibility if there is no choice. It is basically just one cluster.

14:42 <sf-slack> <acomodi> litghost: while waiting for the equivalent tiles to be added to VPR I have added support for CLK_BUFG_TOP/BOT_R tiles using a templated BUFGCTRL primitives. I am currently stuck on routing. What would be the best approach to avoid using the synthetic tile that routes the clk signal and directly use the clk signal out from the BUFG site?

14:43 <sf-slack> <acomodi> I have also added the BUFHCE site just to try to get to a point for which we can use the clock routed from the BUFG site

14:45 <sf-slack> <acomodi> for an initial test I have modified the counter test and inserted the BUFG primitive that take as input the top module clk and its output is used to drive the counter

14:46 <litghost> acomodi: You'll need to create a new ROI harness that leaves the clock at one of the inputs to the BUFGCTRL

14:46 <litghost> acomodi: In the long run, BUFHCE will be a route through

14:46 <sf-slack> <acomodi> I am getting the following kinda-expected routing error: `Cannot route from BLK-TL-CLK_HROW_BOT_R.CLK_HROW_CK_HCLK_OUT_L0[0] (RR node: 213804 type: SOURCE location: (78,130) class: 0) to BLK-TL-SLICEL.CLK[0] (RR node: 194864 type: SINK location: (72,142) class: 44) -- no possible path`

14:47 <litghost> acomodi: Ah, that is because the ROI doesn't include the global clock spine coordinate

14:50 <mithro> acomodi: https://docs.google.com/document/d/1JVWkXxeSanAna8IRt0I49sG4aFS3Unlq693-HsQ0B0U/edit

14:50 <tpb> Title: SymbiFlow Process for Managing non-SymbiFlow Owned Projects - Google Docs (at docs.google.com)

14:52 <sf-slack> <acomodi> litghost: Ok, probably though in my test it should be included. I have forgotten to say that I have changed the ROI to use the bottom left clock region, which actually goes beyond the clock region and includes the first column of the next clock region

14:59 <mithro> acomodi: Does that match what you are doing for VtR?

14:59 <sf-slack> <acomodi> mithro: Yes

15:00 <mithro> acomodi: Great!

15:00 <sf-slack> <acomodi> But actually there is something that should be added

15:00 <sf-slack> <acomodi> Before push forcing it would be good to at least locally test that everything is working within the toolchain

15:02 <sf-slack> <acomodi> so what I always do is to use the local built version of the various tools (VtR in this case) and run `make all_xc7` `make all_ice40` and `make all_v2x_test`

15:08 <mithro> acomodi: How about that?

15:13 <mithro> acomodi: I'm wondering if we should move all these branches under a "pending/" or "wip/" namespace

15:17 <mithro> acomodi: Shall we also retire the "SymbiFlow VtR Upstreaming Status" Google Doc now?

15:19 <sf-slack> <acomodi> mithro: yeah, probably it is a good idea to give a namespace to the branches to make everything more clear

15:19 <mithro> acomodi: Probably first step to writing a short Python script to automate the master+wip process...

15:20 <sf-slack> <acomodi> mithro: and yes, I guess it is possible now to retire the upstreaming status and keep only the github issue trackers

15:22 <sf-slack> <acomodi> mithro: I have been thinking about that as well, probably a bash script is enough. The only problem is that sometimes there are branches which are in conflict (e.g. adding options to VPR affects the same lines of code). I am unsure on which is the best way to handle merge conflicts

15:24 <mithro> acomodi: I would suggest a "semi-automated" Python script, if it hits a merge conflict it drops you to a shell to do the fixs up

15:27 <sf-slack> <acomodi> mithro: sounds good, I'll get to it

15:27 <mithro> acomodi: Want to teach mkurc about it - he should probably pick up doing it for the SymbiFlow/yosys repository?

15:28 <sf-slack> <acomodi> mithro: sure

16:24 <mithro> acomodi: We should probably document https://github.com/SymbiFlow/vtr-verilog-to-routing/projects/1 in the SymbiFlow Process for "Managing non-SymbiFlow Owned Projects" document

16:24 <tpb> Title: Merge changes upstream · GitHub (at github.com)

16:24 <mithro> I had totally forgotten about that...

16:25 <mithro> acomodi: Any thoughts on what the label should be called?

16:26 <sf-slack> <acomodi> mithro: you mean for the branches?

16:26 <mithro> acomodi: Yeah

16:27 <sf-slack> <acomodi> I think `wip` is ok

16:29 <sf-slack> <acomodi> Or maybe we should divide the various issues/branches labels in the different categories (e.g. branches that do not need to be merged upstream like symbiflow-badger, and others that need to go upstream)

16:31 <mithro> acomodi: I'll leave you to think about it and implement what you think is best?

16:32 <sf-slack> <acomodi> mithro: Ok

16:33 <mithro> acomodi: Is there anything in the "Un-merged patches" of https://docs.google.com/document/d/11hlBnzs_1SfzWTVxWYQNDCDxRJFroodoIORaDiWbylw/edit# that is still relavent or should I delete it all now?

16:33 <tpb> Title: [Obsolete] SymbiFlow VtR Upstreaming Status - Google Docs (at docs.google.com)

16:35 <sf-slack> <acomodi> mithro: I need to add the issue about the `common block segfault fix` Other than that everything about it is in the VtR upstreaming project