00:02 <hackerfoo> It works! https://github.com/SymbiFlow/symbiflow-arch-defs/commit/9f9ed215db5538f5ae4b370e5fbd7155f5b785f5

00:02 <tpb> Title: routing works! · SymbiFlow/symbiflow-arch-defs@9f9ed21 · GitHub (at github.com)

16:06 <mithro> kgugala: Can you update https://docs.google.com/document/d/1ngck6LGVTXm6HDrVqWeEGdEELrKPWXVaeejkXurgfl4/edit now the v2x stuff works?

16:06 <tpb> Title: SymbiFlow Parts Encyclopedia - Google Docs (at docs.google.com)

16:11 <mithro> kgugala: Also, I just discovered https://docs.google.com/document/d/1PqNvM5xu-Q6YjMaFy33hXRwzvAqaZqHiO8BQ_qIQV-Q/edit#

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

16:12 <sf-slack3> <kgugala> I don't have access to this one

17:02 <hackerfoo> mkurc: Would you like to work on creating the other IOPAD variants? (containing IOB33S, IOB33 (single))? IOB33S should be the same but with "SELECT_Y 0", the single pads might not be much more work.

17:02 <hackerfoo> I'm not sure what's involved in getting VPR to treat the tiles as equivalent.

17:03 <hackerfoo> And then we'll need the left variants eventually.

18:01 <sf-slack3> <mkurc> @hackerfoo: I can work on that. From my understanding if those tiles are to be equivalent then we do not need to have different models for them. Just a generic one. I'll do some research on that starting from tomorrow.

18:11 <hackerfoo> mkurc: Thanks

19:46 <lromor> Hello everyone, I was wondering what synth_tiles_pinmap.csv contains. Could someone give me a brief explanation?

19:49 <litghost> It maps pad locations to the VPR grid locations, which is required for IO placement constraints

19:52 <lromor> thanks! Noted

22:24 <litghost> lromor: You likely want to use https://github.com/SymbiFlow/symbiflow-arch-defs/pull/1006

22:24 <tpb> Title: Add buttons_arty target by duck2 · Pull Request #1006 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

22:25 <litghost> The ROI that is currently in master doesn't expose many LED's

22:25 <litghost> that PR adds an ROI that exposes more pins

22:25 <litghost> https://github.com/SymbiFlow/prjxray-db/tree/master/artix7/harness

22:25 <tpb> Title: prjxray-db/artix7/harness at master · SymbiFlow/prjxray-db · GitHub (at github.com)

22:26 <lromor[m]> nice, thanks!

22:26 <lromor[m]> * nice, thanks! I'll test the pr.

22:27 <lromor[m]> * nice, thanks! I'll test the pr. what if I wanted to contribute and map some of the remaining pins?

22:28 <litghost> There is an active effort to remove the ROI, but in the mean time you can modify the prjxray harness creation to include your PIN

22:29 <litghost> https://github.com/SymbiFlow/prjxray/blob/master/minitests/roi_harness/runme.tcl#L152

22:29 <tpb> Title: prjxray/runme.tcl at master · SymbiFlow/prjxray · GitHub (at github.com)

22:30 <litghost> The root level prjxray has a target that shows how to invoke the make command to rebuild the harness: https://github.com/SymbiFlow/prjxray/blob/master/Makefile#L129

22:30 <tpb> Title: prjxray/Makefile at master · SymbiFlow/prjxray · GitHub (at github.com)

22:30 <lromor[m]> Thanks! I have everything built locally so it won't be a problem. Could you elaborate why there's an effort of removing the ROI? What does that mean?

22:31 <litghost> Currently we have Vivado build us a "harness" that handles the IO stuff so we could initially focus on LUTs/BRAMs/FFs, etc

22:32 <litghost> We no longer require the harness, and are working on removing it, which would allow mapping of any available pin without modifying the harness

22:32 <lromor[m]> Ah. I see. Thank you.