| *** tpb has joined #symbiflow | 00:00 | |
| *** futarisIRCcloud has joined #symbiflow | 00:01 | |
| *** airship has joined #symbiflow | 01:58 | |
| *** airship has quit IRC | 02:06 | |
| *** citypw has joined #symbiflow | 03:04 | |
| *** proteusguy has quit IRC | 03:51 | |
| *** Bertl is now known as Bertl_zZ | 05:40 | |
| *** citypw has quit IRC | 06:17 | |
| *** proteusguy has joined #symbiflow | 06:18 | |
| *** OmniMancer has joined #symbiflow | 06:22 | |
| *** citypw has joined #symbiflow | 06:30 | |
| *** kraiskil has joined #symbiflow | 07:42 | |
| *** acomodi has joined #symbiflow | 09:01 | |
| *** futarisIRCcloud has quit IRC | 09:17 | |
| *** citypw has quit IRC | 09:59 | |
| *** proteusguy has quit IRC | 10:34 | |
| sf-slack1 | <mkurc> I have a question regarding 7-series CLB architecture: There is an interconnect in each CLB through which two SLICEs are connected to a "Center" interconnect (that is how Vivado calls it). I've also found pip definitions for it in the CLB tile-type JSON file. | 11:55 |
|---|---|---|
| sf-slack1 | <mkurc> But are these pips actually there? I couldn't find any bits related to them and the CLB interconnect provides only 1:1 connections between each slice and the "center" interconnect. | 11:56 |
| sf-slack1 | <mkurc> Also couldn't find any evidence that these pips are somehow relevant for the VPR. | 11:57 |
| sf-slack1 | <mkurc> So can I treat the interconnect within a CLB as transparent and skip it completely when defining an universal eg. SLICEL tile ? | 11:58 |
| sf-slack1 | <acomodi> @mkurc They most probably are `ppips` if they have 1:1 connections | 11:59 |
| sf-slack1 | <mkurc> hmmm | 12:00 |
| sf-slack1 | <mkurc> eg. in `tile_type_CLBLL_L.json` there is a filled in section called `pips`. But I couldn't find any piece of code that refers to that section for importing its data to the VPR | 12:01 |
| sf-slack1 | <mkurc> If so, then the VPR does not care about these pips. And I couldn't find any bits related to them in the database. | 12:02 |
| sf-slack1 | <acomodi> yep, but those ppips have to be present in the db, otherwise there will be an error in the `frames` step of symbiflow. I think VPR needs to know only that there is a connection there (CLB --> Center_INT) | 12:04 |
| sf-slack1 | <mkurc> Agree, CLB -> Center_INT. But not SLICE_X0Y0 -> CLB pins and SLICE_X1Y0 -> CLB pins. | 12:05 |
| sf-slack1 | <acomodi> What you mean by "But not SLICE_X0Y0 -> CLB pins and SLICE_X1Y0 -> CLB pins"? | 12:12 |
| sf-slack1 | <mkurc> Meaning that there are pips inside a CLB that define connections between SLICEs and outgoing tile pins. | 12:13 |
| sf-slack1 | <acomodi> Yes, and I believe that all of these pips are actually `ppips` and have no bits | 12:19 |
| sf-slack1 | <mkurc> Ok, thanks | 12:19 |
| *** Bertl_zZ is now known as Bertl | 14:03 | |
| *** Bertl is now known as Bertl_oO | 14:37 | |
| *** citypw has joined #symbiflow | 15:09 | |
| *** sxpert has quit IRC | 15:24 | |
| *** OmniMancer has quit IRC | 15:54 | |
| *** sxpert has joined #symbiflow | 16:04 | |
| *** citypw has quit IRC | 16:35 | |
| litghost | mkurc: Those pips are used for routing import here https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/utils/prjxray_create_edges.py#L834 | 16:43 |
| tpb | Title: symbiflow-arch-defs/prjxray_create_edges.py at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 16:43 |
| litghost | mkurc: acomodi's analysis is that those pips are all 1:1, and so are ppips (e.g. no configuration), however those pips relate the site pin wires to the CLBLx_x wires that connect to the interconnect per tile conn | 16:44 |
| *** filt3r has joined #symbiflow | 17:07 | |
| mithro | Just FYI - I've updated the dependabot for prjxray to only send pull requests once a week | 17:16 |
| *** i8hantanu has quit IRC | 17:17 | |
| *** Bertl_oO is now known as Bertl | 17:30 | |
| *** kraiskil has quit IRC | 17:31 | |
| sf-slack1 | <mkurc> @litghost: Thanks. So if there is no pip between a site pin and a tile wire within a tile then no connection will be formed ? | 17:39 |
| litghost | mkurc: pips are always between tile wires, so your question is ill-formed. Can you rephrase? | 17:41 |
| sf-slack1 | <mkurc> @lighost: In a tile definition file (eg `tile_type_CLBLL.json`) there is a section "wires" which holds all wires within that tile. Then, there is a "sites" section which holds site information. And then each site has its section named "site_pins" which defines which pin of the site is connected to which wire within the tile. | 17:45 |
| sf-slack1 | <mkurc> And there is also a section "pips" which define pips. | 17:45 |
| sf-slack1 | <mkurc> And connections defined within the whole structure are like that: site_pin -> site_wire -> pip -> tile_wire. | 17:46 |
| sf-slack1 | <mkurc> And my question is when the name of site_wire is equal to name of tile_wire (no pip) is it considered as a connection ? | 17:46 |
| litghost | mkurc: Incorrect | 17:57 |
| litghost | mkurc: site_pin -> tile_wire -> pip ... | 17:57 |
| litghost | mkurc: site_wire's only exist within a site | 17:57 |
| sf-slack1 | <mkurc> Ahhh, now I see. | 17:58 |
| litghost | mkurc: I've sent https://docs.google.com/document/d/1iElkfCf9jiE5QiQYh5RAXVrjHU9t2n4M_xiSh5m5BaI/edit to you, but here it is again | 17:58 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 17:58 |
| sf-slack1 | <mkurc> @litghost: I see it has been updated. Thanks. | 18:00 |
| litghost | mkurc: Nothing has materially changed | 18:00 |
| litghost | mkurc: Some diagrams were added, but the original contents were correct | 18:00 |
| sf-slack1 | <mkurc> Yes, it was. But the diagrams make it easier to understand some nuances. | 18:02 |
| *** kraiskil has joined #symbiflow | 18:10 | |
| *** kraiskil has quit IRC | 19:00 | |
| sf-slack1 | <acomodi> litghost: how do we proceed with the VTR patches isolation? | 19:07 |
| litghost | acomodi: Not sure what you mean? Can you not create PR's for the items you've identified? | 19:08 |
| sf-slack1 | <acomodi> litghost: Ok, I'll proceed with opening all the different PRs upstream after having double checked that they are independent. The eblif related ones are correct in the docs or there are some items missing? | 19:19 |
| *** Bertl is now known as Bertl_oO | 19:32 | |
| litghost | acomodi: eblif is a non-standard blif extension, so extended support is something we've been working on. I believe there is some documentation in yosys, but we probably need to add something to VPR too. I believe that VPR might already have upstream eblif read support, those commits were adding eblif write support? Double check | 19:34 |
| *** kraiskil has joined #symbiflow | 21:21 | |
| mithro | litghost: Did you find https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/365 | 21:24 |
| tpb | Title: Support packing when modes provide different routing by mithro · Pull Request #365 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 21:24 |
| mithro | litghost: It has a test example of the routing modes stuff | 21:25 |
| litghost | mithro: I believe so, but I'm taking a different approach initially | 21:25 |
| mithro | litghost: Okay | 21:33 |
| *** kraiskil has quit IRC | 21:59 | |
| mithro | litghost: This is what we currently say -> https://summerofcode.withgoogle.com/organizations/4517422304854016/ | 22:16 |
| mithro | litghost: Our GSoC page is at https://symbiflow.github.io/summer-of-code | 22:17 |
| tpb | Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io) | 22:17 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!