| *** tpb has joined #symbiflow | 00:00 | |
| *** sudo-sh has joined #symbiflow | 02:12 | |
| *** sudo-sh has quit IRC | 02:28 | |
| *** Bertl is now known as Bertl_zZ | 02:55 | |
| *** citypw has joined #symbiflow | 03:14 | |
| *** OmniMancer has joined #symbiflow | 06:09 | |
| *** sudo-sh has joined #symbiflow | 07:34 | |
| *** _whitelogger has quit IRC | 08:05 | |
| *** _whitelogger has joined #symbiflow | 08:08 | |
| *** sudo-sh has quit IRC | 08:30 | |
| *** celadon_ has joined #symbiflow | 09:40 | |
| *** celadon has quit IRC | 09:41 | |
| *** citypw has quit IRC | 09:52 | |
| *** makrusak has joined #symbiflow | 09:55 | |
| *** makrusak has quit IRC | 11:21 | |
| *** Bertl_zZ is now known as Bertl | 11:24 | |
| *** Girish has joined #symbiflow | 12:48 | |
| Girish | can anybody tell me project details | 12:50 |
|---|---|---|
| *** makrusak has joined #symbiflow | 12: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 IRC | 13:35 | |
| *** proteusguy has quit IRC | 13:48 | |
| *** Miyu has joined #symbiflow | 13:50 | |
| *** Girish has quit IRC | 13:51 | |
| *** OmniMancer has quit IRC | 14:30 | |
| litghost | For which tile? | 15:10 |
| sf-slack1 | <mkurc> these are present in all CLBs | 15:12 |
| 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 | 15:16 |
| *** sxpert has quit IRC | 15:20 | |
| litghost | mkurc: 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.json | 15: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 passtrhough | 15:23 |
| sf-slack1 | <mkurc> @litghost And these wires are listed in many tile types but they never connected to anything. Just listed | 15:24 |
| *** sxpert has joined #symbiflow | 15:33 | |
| *** citypw has joined #symbiflow | 15:37 | |
| 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? | 15:42 |
| *** citypw has quit IRC | 15:42 | |
| sf-slack1 | <mkurc> @litghost: Sure: https://github.com/SymbiFlow/prjxray-db/blob/master/artix7/tile_type_CLBLM_L.json See line 1190 | 15:44 |
| tpb | Title: prjxray-db/tile_type_CLBLM_L.json at master · SymbiFlow/prjxray-db · GitHub (at github.com) | 15:44 |
| litghost | mkurc: Note, you said _EE2A0_0 was located in a CLB, it is not. You linked to CLBLM_EE2A0 | 15:46 |
| litghost | which would be _EE2A0 | 15:46 |
| sf-slack1 | <mkurc> @litghost: Oh, sorry... | 15:47 |
| sf-slack1 | <mkurc> I meant _EE2A0, _EE2A1 etc. | 15:47 |
| litghost | Anyways, I reiterate my previous points. That is a flyover over, and must be preserved. | 15:47 |
| litghost | flyover wire* | 15:47 |
| sf-slack1 | <mkurc> Yeah, right. | 15:47 |
| *** makrusak has quit IRC | 17:07 | |
| mithro | litghost: When you get a moment, could you take a look at https://github.com/leon575777642/vprgen | 18:11 |
| tpb | Title: GitHub - leon575777642/vprgen: VPRs architecture description and routing resource graph XML generation API (at github.com) | 18:11 |
| *** _whitelogger has quit IRC | 18:43 | |
| *** _whitelogger has joined #symbiflow | 18:46 | |
| litghost | mithro: What am I looking for? | 21:25 |
| mithro | litghost: We are trying to put together a Python API for generating VPR XML files | 21:26 |
| litghost | mithro: arch or rrgraph? | 21:27 |
| mithro | litghost: Both | 21:27 |
| 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 | 21:28 |
| 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 | 21:29 |
| mithro | https://docs.google.com/document/d/1Pd_ygB0PvSq_gPEYIm8sJEF-mYY2nk3kLsazLVL21uw/edit# | 21:32 |
| tpb | Title: VtR Python API Design Doc - Google Docs (at docs.google.com) | 21:32 |
| 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 | 21:35 |
| mithro | litghost: The idea is that the "XML" part of file format can be replaced at a later date? | 21:35 |
| 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. | 21:36 |
| 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 | 21:37 |
| litghost | mithro: Ultimately, the idea format is an array of nodes an extremely efficient way to built the edge graph | 21:38 |
| litghost | ideal* | 21:38 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!