07:25 <sf-slack> <mkurc> @timo.callahan If you are interested about BUFR support there is a WIP branch with that. I worked on that quite some time ago so it is outdated and may require some work to get integrated. The thing I've discovered was that even though I've emitted all the fasm features for BUFR (presumably) correctly it didn't work in hardware. https://github.com/antmicro/symbiflow-arch-defs/tree/bufr_support

07:25 <tpb> Title: GitHub - antmicro/symbiflow-arch-defs at bufr_support (at github.com)

07:34 <sf-slack> <timo.callahan> Thanks @mkurc . It is not at all urgent. My interest in BUFR was just to see if I could use it with arty-swbut, which is what the small counter test uses. It seems the answer is "no", even if BUFR support is completed in Symbiflow, since arty-swbut has no clocking elements.

15:49 <sf-slack> <timo.callahan> Hmm, I'm still having difficulty integrating the split CLBs change with my 100T changes. I get errors in fasm2frames for a few IOB33s; the missing feature is ".....LVTTL_SSTL135_SSTL15.SLEW.SLOW" in most cases, although there is also one "...__S_STL15.IN_ONLY". Is this a known issue?

15:53 <sf-slack> <mkurc> @timo.callahan The SSTL15 support has been merged. This error shouldn't appear once you rebase on the most recent master

15:54 <sf-slack> <mkurc> You may also check that all the submodules are checked out correctly, especially prjxray and prjxray-db

15:55 <sf-slack> <timo.callahan> Thanks @mkurc, I'll rerun after pulling the latest upstream, and make sure I do the "make env", which updates the submodules. Oh, there's changes in prjxray-db that go along with the code changes?

15:55 <sf-slack> <timo.callahan> Maybe that's the problem, since I'm using my own copy of prjxray-db for the 100T changes.

15:58 <sf-slack> <mkurc> So for that change everything has to be in sync. The prjxray-db holds fasm features definitions but also prjxray is important as it holds the fasm2frames tool. That tool adds some fasm features on its own for the PUDC_B special IOB site. Both has to match.

20:32 <andrewb1999> If I wanted to generate architectures for the xc7z020clg400-1 instead of the xc7z020clg484-1 that is currently in the prjxray db, do I just need to generate a new package_pins.csv or would other device specific files change?

20:33 <andrewb1999> I'm trying to add support for the Pynq-z1 board which uses the xc7z020clg400-1

20:34 <sf-slack> <timo.callahan> Hi @andrewb1999, I've done something similar for the xc7a100t parts. Hold on while I find some info.

20:44 <sf-slack> <timo.callahan> Here is a writeup I did on my 100T experience: https://github.com/tcal-x/prjxray/blob/doc/NEWPART.md See the part under "Step 3" about adding new steps to "db-extras-zynq7-harness" in your case. Then you do "make db-extras-zynq7-harness". Hmm, I see there are no actions for that target currently, so it might be a little tricky. Also, I don't see z020 getting built -- do you have local changes for that?

20:44 <tpb> Title: prjxray/NEWPART.md at doc · tcal-x/prjxray · GitHub (at github.com)

20:45 <litghost> Looks like we've disabled the z7020 configuration from the root makefile: https://github.com/SymbiFlow/prjxray/blob/master/Makefile#L160

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

20:45 <litghost> Wait I have that backwards

20:45 <litghost> zynq7 is z7020, per https://github.com/SymbiFlow/prjxray/blob/master/settings/zynq7.sh#L2

20:45 <tpb> Title: prjxray/zynq7.sh at master · SymbiFlow/prjxray · GitHub (at github.com)

20:45 <litghost> So adding the new part per the above doc should work

20:46 <litghost> Actually, it is simplier sorry

20:46 <litghost> andrewb1999: You just need to add a line like https://github.com/SymbiFlow/prjxray/blob/master/Makefile#L185-L188 to https://github.com/SymbiFlow/prjxray/blob/master/Makefile#L223

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

20:47 <andrewb1999> timo.callahan: I have local changes in symbiflow-arch-defs to build the z020 but don't have any local changes for prjxray

20:47 <litghost> Basically the tilegrid and tileconn are the same, but the package pins <-> sites loc is different

20:47 <andrewb1999> litghost: Ok I'll try that, thanks!

20:47 <litghost> andrewb1999: When you have the extras working, please submit a PR! Thanks!

20:47 <andrewb1999> litghost: Will do!

22:12 <andrewb1999> Ok I have a bitstream generated for the pynq board. Does anyone know how to find information to create an openocd config for it? It seems like a zedboard config exists in the openocd repo but not a pynq-z1 config.

22:39 <sf-slack> <timo.callahan> @mithro, @litghost, I'm back to having things working after integrating recent changes on symbiflow-arch-defs. Do I need a prjxray-db build _before_ sending the PR? I have new tests such as "counter_arty100t_bin" that would fail without the prjxray-db updates. Would CI automatically run these new tests, or does CI have an explicit list of tests that it runs?

22:56 <litghost> timo.callahan: You can send the PR before the new prjxray-db, how it will be red CI until you update the PR with the new submodule hash

22:56 <litghost> timo.callahan: I recommend you first get the prjxray PR up, and then get the symbiflow-arch-defs PR up for review

22:56 <mithro> @timo.callahan: I'll do a prjxray-db push now

22:57 <litghost> andrewb1999: Do you know how to define an openocd adapater config?

22:57 <litghost> andrewb1999: You should only need to define the adapter config for the pynq board. If you have the board schematic, it shouldn't be too hard

22:58 <mithro> @timo.callahan: Is acb6210a7606c5fd72e5ea729aedb37be23f505d new enough?

23:00 <sf-slack> <timo.callahan> Let me check; my last change just merged this morning.

23:02 <mithro> Actually - The latest successful run was acb6210a7606c5fd72e5ea729aedb37be23f505d

23:03 <sf-slack> <timo.callahan> On prjxray, I need 4a7983b4ea392aabd93a67a68fcb65bcb4effef8

23:31 <mithro> @timo.callahan: Will have to wait for a bit longer then