Monday, 2019-03-11

*** tpb has joined #symbiflow00:00
*** sudo-sh has joined #symbiflow02:12
*** sudo-sh has quit IRC02:28
*** Bertl is now known as Bertl_zZ02:55
*** citypw has joined #symbiflow03:14
*** OmniMancer has joined #symbiflow06:09
*** sudo-sh has joined #symbiflow07:34
*** _whitelogger has quit IRC08:05
*** _whitelogger has joined #symbiflow08:08
*** sudo-sh has quit IRC08:30
*** celadon_ has joined #symbiflow09:40
*** celadon has quit IRC09:41
*** citypw has quit IRC09:52
*** makrusak has joined #symbiflow09:55
*** makrusak has quit IRC11:21
*** Bertl_zZ is now known as Bertl11:24
*** Girish has joined #symbiflow12:48
Girishcan anybody tell me project details12:50
*** makrusak has joined #symbiflow12:51
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.13:01
*** Miyu has quit IRC13:35
*** proteusguy has quit IRC13:48
*** Miyu has joined #symbiflow13:50
*** Girish has quit IRC13:51
*** OmniMancer has quit IRC14:30
litghostFor which tile?15:10
sf-slack1<mkurc> these are present in all CLBs15:12
litghostmkurc: 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 split15:16
*** sxpert has quit IRC15:20
litghostmkurc: Why do you believe _EE2A0_0 or _EE2A0_1 are located within a CLB?15:21
sf-slack1<mkurc> @litghost Because they are listed in "wires" section eg. in tile_type_CLBLM_L.json15:22
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 passtrhough15:23
sf-slack1<mkurc> @litghost And these wires are listed in many tile types but they never connected to anything. Just listed15:24
*** sxpert has joined #symbiflow15:33
*** citypw has joined #symbiflow15:37
litghostmkurc: I just checked, I don't believe those wires are located in the clblm.json, can you link to an example on GitHub?15:42
*** citypw has quit IRC15:42
sf-slack1<mkurc> @litghost: Sure: See line 119015:44
tpbTitle: prjxray-db/tile_type_CLBLM_L.json at master · SymbiFlow/prjxray-db · GitHub (at
litghostmkurc: Note, you said _EE2A0_0 was located in a CLB, it is not.  You linked to CLBLM_EE2A015:46
litghostwhich would be _EE2A015:46
sf-slack1<mkurc> @litghost: Oh, sorry...15:47
sf-slack1<mkurc> I meant _EE2A0, _EE2A1 etc.15:47
litghostAnyways, I reiterate my previous points.  That is a flyover over, and must be preserved.15:47
litghostflyover wire*15:47
sf-slack1<mkurc> Yeah, right.15:47
*** makrusak has quit IRC17:07
mithrolitghost: When you get a moment, could you take a look at
tpbTitle: GitHub - leon575777642/vprgen: VPRs architecture description and routing resource graph XML generation API (at
*** _whitelogger has quit IRC18:43
*** _whitelogger has joined #symbiflow18:46
litghostmithro: What am I looking for?21:25
mithrolitghost: We are trying to put together a Python API for generating VPR XML files21:26
litghostmithro: arch or rrgraph?21:27
mithrolitghost: Both21:27
litghostmithro:  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 real21:28
litghostmithro: 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 rrgraphs21:29
tpbTitle: VtR Python API Design Doc - Google Docs (at
litghostmithro: 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 serialization21:35
mithrolitghost: The idea is that the "XML" part of file format can be replaced at a later date?21:35
litghostmithro: 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.21:36
litghostmithro: 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 formats21:37
litghostmithro: Ultimately, the idea format is an array of nodes an extremely efficient way to built the edge graph21:38

Generated by 2.13.1 by Marius Gedminas - find it at!