Monday, 2019-03-25

*** tpb has joined #symbiflow00:00
*** futarisIRCcloud has joined #symbiflow00:01
*** airship has joined #symbiflow01:58
*** airship has quit IRC02:06
*** citypw has joined #symbiflow03:04
*** proteusguy has quit IRC03:51
*** Bertl is now known as Bertl_zZ05:40
*** citypw has quit IRC06:17
*** proteusguy has joined #symbiflow06:18
*** OmniMancer has joined #symbiflow06:22
*** citypw has joined #symbiflow06:30
*** kraiskil has joined #symbiflow07:42
*** acomodi has joined #symbiflow09:01
*** futarisIRCcloud has quit IRC09:17
*** citypw has quit IRC09:59
*** proteusguy has quit IRC10: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 connections11:59
sf-slack1<mkurc> hmmm12: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 VPR12: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 bits12:19
sf-slack1<mkurc> Ok, thanks12:19
*** Bertl_zZ is now known as Bertl14:03
*** Bertl is now known as Bertl_oO14:37
*** citypw has joined #symbiflow15:09
*** sxpert has quit IRC15:24
*** OmniMancer has quit IRC15:54
*** sxpert has joined #symbiflow16:04
*** citypw has quit IRC16:35
litghostmkurc: Those pips are used for routing import here
tpbTitle: symbiflow-arch-defs/ at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostmkurc: 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 conn16:44
*** filt3r has joined #symbiflow17:07
mithroJust FYI - I've updated the dependabot for prjxray to only send pull requests once a week17:16
*** i8hantanu has quit IRC17:17
*** Bertl_oO is now known as Bertl17:30
*** kraiskil has quit IRC17: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
litghostmkurc: 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
litghostmkurc: Incorrect17:57
litghostmkurc: site_pin -> tile_wire -> pip ...17:57
litghostmkurc: site_wire's only exist within a site17:57
sf-slack1<mkurc> Ahhh, now I see.17:58
litghostmkurc: I've sent to you, but here it is again17:58
tpbTitle: Google Docs - create and edit documents online, for free. (at
sf-slack1<mkurc> @litghost: I see it has been updated. Thanks.18:00
litghostmkurc: Nothing has materially changed18:00
litghostmkurc: Some diagrams were added, but the original contents were correct18:00
sf-slack1<mkurc> Yes, it was. But the diagrams make it easier to understand some nuances.18:02
*** kraiskil has joined #symbiflow18:10
*** kraiskil has quit IRC19:00
sf-slack1<acomodi> litghost: how do we proceed with the VTR patches isolation?19:07
litghostacomodi: 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_oO19:32
litghostacomodi: 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 check19:34
*** kraiskil has joined #symbiflow21:21
mithrolitghost: Did you find
tpbTitle: Support packing when modes provide different routing by mithro · Pull Request #365 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithrolitghost: It has a test example of the routing modes stuff21:25
litghostmithro: I believe so, but I'm taking a different approach initially21:25
mithrolitghost: Okay21:33
*** kraiskil has quit IRC21:59
mithrolitghost: This is what we currently say ->
mithrolitghost: Our GSoC page is at
tpbTitle: SymbiFlow - the GCC of FPGAs (at

Generated by 2.13.1 by Marius Gedminas - find it at!