<sf-slack1>
<mkurc> Can anybody tell what are wires named "*_EE2A0_0", "*_EE2A0_1" and so on for? I've looked through the 7-series connection database and tile type definitions. I couldn't find any pip or site connected to such a wire but these wires are present eg. in connection rules between neighboring CLBs. The question is should I preserve them during tile split.
Miyu has quit [Ping timeout: 245 seconds]
proteusguy has quit [Remote host closed the connection]
Miyu has joined #symbiflow
Girish has quit [Ping timeout: 256 seconds]
OmniMancer has quit [Quit: Leaving.]
<litghost>
For which tile?
<sf-slack1>
<mkurc> these are present in all CLBs
<litghost>
mkurc: Those are flyover wires. In general I recommend that you don't process tileconn.json at all. It is not required to implement the tile split
sxpert has quit [Ping timeout: 257 seconds]
<litghost>
mkurc: Why do you believe _EE2A0_0 or _EE2A0_1 are located within a CLB?
<sf-slack1>
<mkurc> @litghost Because they are listed in "wires" section eg. in tile_type_CLBLM_L.json
<sf-slack1>
<mkurc> @litghost But they are not connected anywhere, neither to any site nor to any pip within that tile. So they are just a passtrhough
<sf-slack1>
<mkurc> @litghost And these wires are listed in many tile types but they never connected to anything. Just listed
sxpert has joined #symbiflow
citypw has joined #symbiflow
<litghost>
mkurc: I just checked, I don't believe those wires are located in the clblm.json, can you link to an example on GitHub?
<tpb>
Title: GitHub - leon575777642/vprgen: VPRs architecture description and routing resource graph XML generation API (at github.com)
_whitelogger has joined #symbiflow
<litghost>
mithro: What am I looking for?
<mithro>
litghost: We are trying to put together a Python API for generating VPR XML files
<litghost>
mithro: arch or rrgraph?
<mithro>
litghost: Both
<litghost>
mithro: That code is waaaaay to slow to emit an rrgraph in a timely fashion. The current a7 rrgraph has 5 million edges, and it is only 1/5 of a part. Some of those edges can be reduced, but at most half of those edges are real
<litghost>
mithro: If you want to be able to scale to max size parts, even the current code is going to be costly. XML is a dead end for representing large rrgraphs
<tpb>
Title: VtR Python API Design Doc - Google Docs (at docs.google.com)
<litghost>
mithro: If we are going to continue to use python to emit rrgraphs, there can be basically no object model for edges, and for nodes there is basically no value in a library except for a map. It is unclear the value proposition to an API that is more capable of import, add_node and serialization
<mithro>
litghost: The idea is that the "XML" part of file format can be replaced at a later date?
<litghost>
mithro: The non-graph parts of the rrgraph are not interesting, and the graph parts (rr node/edge) need to be as light-weight as possible. Keep in mind we are talking rrgraphs with 1-100 million edges. Just the act of calling a constructor 100 million times adds up.
<litghost>
mithro: You are thinking about the replacement of XML backwards. Rather than do more modeling of the storage, we need less. The VTR devs talked about this. What we need is an API at the VPR level, and plugins for various formats
<litghost>
mithro: Ultimately, the idea format is an array of nodes an extremely efficient way to built the edge graph