01:08 <hackerfoo> Has anyone considered using types in the SymbiFlow Python scripts? e.g. https://github.com/python-attrs/attrs

01:08 <tpb> Title: GitHub - python-attrs/attrs: Python Classes Without Boilerplate (at github.com)

01:09 <hackerfoo> A lot of the documentation seems to be listing the expected types.

08:33 <sf-slack2> <acomodi> mithro: I think I don't understood correctly: you mean including the VtR CI test suite to the SymbiFlow-arch-defs repo? Or run VtR tests with Kokoro in the SymbiFlow/VtR fork?

15:01 <mithro> acomodi: I mean run VtR tests with Kokoro on the SymbiFlow/VtR fork

15:06 <sf-slack2> <acomodi> mithro: all right, instead of using Travis CI or alongside them? Because right now a standard CI run of VtR takes ~1h

15:07 <sf-slack2> <acomodi> mithro: which is acceptable I suppose

15:11 <mithro> acomodi: I was thinking from the idea of getting you the QoR values automatically for every branch without you having to run things manually

15:14 <sf-slack2> <acomodi> mithro: Ah all right, I thought you meant to move to kokoro the standard Travis CI

15:14 <mithro> acomodi: No

15:14 <sf-slack2> <acomodi> mithro: I think that it makes sense, but it would be better to kick off the builds manually

15:14 <sf-slack2> <acomodi> mithro: not everytime a commit is pushed

15:14 <mithro> acomodi: Why?

15:17 <sf-slack2> <acomodi> mithro: Titan benchmarks take actually more than one day to finish on the cloud machine. If we have many branches that need to be checked simultaneously it could require a longer time (plus the fact that if running all the different benchmarks all at once RAM usage goes beyond 250G)

15:18 <sf-slack2> <acomodi> mithro: IMO it would be better to kick off a QoR measurements only when the branch is ready to be compared against master (with something like `force kokoro-run` label)

15:18 <mithro> acomodi: Issue is there is no way to add a label just to a branch....

15:20 <litghost> mithro: Is there a cron equiv for kokoro?

15:20 <mithro> litghost: Kinda...

17:23 <hackerfoo> litghost: I'm having trouble understanding how to handle multiple site instances of the same type, specifically {I,O]LOGICE3.

17:23 <hackerfoo> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_tile_import.py#L84-L108

17:23 <tpb> Title: symbiflow-arch-defs/prjxray_tile_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:24 <litghost> I thought we were splitting the tile?

17:24 <litghost> so each tile would end up having only one ILOGICE3?

17:24 <hackerfoo> Should there be something like IOLOGICE3/IOLOGICE3H,IOLOGICE3/IOLOGICE3H in the --site_types argument?

17:25 <hackerfoo> I was trying to implement the joining part first.

17:25 <litghost> Ah, so simply joining the IOB and IOI?

17:25 <hackerfoo> Yeah

17:25 <litghost> Well if you ask the script to output the IOI3, it should just work

17:26 <hackerfoo> Alternatively, how do I get the script to split on Y0/Y1?

17:26 <litghost> What its doing is mapping multiples of the same site to num_pb, and then indexing them

17:26 <hackerfoo> It works for RIOI3, but I don't want to manually implement the rest.

17:26 <litghost> You'll need to write code to do anything other than just output either a tile as is, or a tile per site (which is not what we want in this case)

17:26 <litghost> You'll need to implement something to handle 2 prjxray tiles -> 1 VPR tile

17:27 <litghost> That has never been required prior to now

17:27 <litghost> The script supports 1 prjxray tile -> 1 VPR tile and 1 prjxray tile -> 1 VPR tile per site

17:27 <litghost> neither of which is what you want

17:27 <hackerfoo> Okay. So I do need to implement splitting on some criteria.

17:28 <hackerfoo> Maybe just hardcode splitting on Y for now.

17:28 <litghost> I thought you just said that you were starting with joining and no split?

17:28 <hackerfoo> I was, but the script doesn't seem to work at all when there are multiple sites of the same type.

17:30 <hackerfoo> If I pass in one of each type to --site_types, the first line fails, if I pass in two, the second fails: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_tile_import.py#L394-L416

17:30 <tpb> Title: symbiflow-arch-defs/prjxray_tile_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:31 <hackerfoo> And it's not clear how to fix it, since it seems odd to pass in multiple of each type, but the script seems to expect it.

17:31 <litghost> CLBLL_L import used to work, I expect you are just using it wrong

17:31 <hackerfoo> Probably. But I still don't understand it.

17:31 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/archs/artix7/tiles/clbll_l/CMakeLists.txt

17:31 <tpb> Title: symbiflow-arch-defs/CMakeLists.txt at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:32 <litghost> The old CLBLL_L tile CMake definition is still present

17:32 <litghost> Does it work as expected?

17:32 <litghost> It is worth noting that the 1 type per SITE_TYPES is not required, but was added later

17:34 <litghost> Last time 1 tile, multiple sites was used is https://github.com/SymbiFlow/symbiflow-arch-defs/tree/393e85351aa3924df097547daddd77e29f3a3b79

17:34 <tpb> Title: GitHub - SymbiFlow/symbiflow-arch-defs at 393e85351aa3924df097547daddd77e29f3a3b79 (at github.com)

17:34 <hackerfoo> Okay, so I need a file per instance: https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/primitives/slicel/CMakeLists.txt

17:34 <tpb> Title: symbiflow-arch-defs/CMakeLists.txt at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:34 <litghost> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/393e85351aa3924df097547daddd77e29f3a3b79/artix7/tiles/clbll_l/CMakeLists.txt

17:34 <tpb> Title: symbiflow-arch-defs/CMakeLists.txt at 393e85351aa3924df097547daddd77e29f3a3b79 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:34 <litghost> File per instance is not required

17:34 <litghost> Or was not required in the past

17:35 <litghost> File per instance was used for a bit for SLICEL because of a carry chain issue

17:35 <litghost> Which is no longer relevant

17:36 <hackerfoo> cmake seems to expect a target for each TYPE/INSTANCE in SITE_TYPES

17:38 <litghost> Sort of

17:38 <litghost> It wants a path-like thing

17:38 <litghost> so ilogic3/ilogic3 is okay

17:40 <litghost> So for example

17:40 <litghost> is probably fine

17:40 <litghost> SITE_TYPES ILOGIC3/ILOGIC3 ILOGIC3/ILOGIC3

17:40 <hackerfoo> No, it'll fail the assertion.

17:40 <hackerfoo> They need different instance names.

17:41 <litghost> Which assertion?

17:41 <hackerfoo> https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_tile_import.py#L413-L415

17:41 <tpb> Title: symbiflow-arch-defs/prjxray_tile_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:42 <hackerfoo> `site_instance` is the name

17:44 <litghost> Agreed that assertion will fire, but I think in this case the code is overly restrictive, it just needs a proper key. The assertion should read:

17:44 <litghost> "is the key to site_type_ports unique"

17:44 <litghost> Which the current code fails if you repeat a site instance type

17:45 <litghost> object_ref (https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_tile_import.py#L76) supports site instance indicies

17:45 <tpb> Title: symbiflow-arch-defs/prjxray_tile_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:45 <litghost> In the short term, making N copies of the IOI sites will resolve the relevant issue

17:45 <litghost> But prjxray_tile_import can/did support multiple instances of a single site

17:47 <litghost> And the cells_idx list is still being built https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_tile_import.py#L390

17:47 <tpb> Title: symbiflow-arch-defs/prjxray_tile_import.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

21:53 <mithro> FYI - I have pushed the latest database as of a couple of hours ago

23:11 <hackerfoo> It looks like I have to make the same modifications to prjxray_physical_tile_import.py to merge tiles.