Monday, 2019-02-25

*** tpb has joined #symbiflow00:00
*** _whitelogger has quit IRC01:46
*** _whitelogger has joined #symbiflow01:48
*** citypw has joined #symbiflow03:22
*** citypw has quit IRC03:39
*** citypw has joined #symbiflow03:45
*** citypw has quit IRC03:48
*** citypw has joined #symbiflow03:49
*** citypw has quit IRC05:19
*** citypw has joined #symbiflow05:28
*** OmniMancer has joined #symbiflow06:04
*** _whitelogger has quit IRC06:16
*** _whitelogger has joined #symbiflow06:18
*** citypw has quit IRC10:06
*** _whitelogger has quit IRC12:46
*** _whitelogger has joined #symbiflow12:48
*** OmniMancer has quit IRC12:50
sf-slack<acomodi> Hi, I have been making progress on the slicem issue and made a PR ( that should be able to solve the problem. Further explanations of my findings can be seen in the PR itself13:12
tpbTitle: d_dram.pb_type: update xml definition to solve slicem issue by acomodi · Pull Request #402 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** proteusguy has joined #symbiflow13:32
sf-slack<mkurc> Hi, I've started working on conversion of top-level CLBs to slices so the VPR will operate on slice base. I'll try to modify the architecture XML file and the routing graph instead of tools which build them.13:36
sf-slack<tmichalak> Hi Guys, I am still struggling with the placer issue for the carry chains ( The architecture XMLs seem to be in order, hence the bug must be somewhere in the clustering part...13:41
tpbTitle: Placer cannot handle slice_l and slice_r carry chains in the same CLB · Issue #8 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
sf-slack<mkurc> I've been thinking: Is the routing graph correct? Assuming that the VPR uses the routing graph to determine how to place/connect carry chains (right?), the problem might be there somwhere.13:44
sf-slack<kgugala> @mkurc yes, it tries to pack a molecule and then it checks if the packing is routable15:49
sf-slack<kgugala> I think mithro described that somwhere above15:50
mithrokgugala: So, looking at the architecture definition the multiple carry chains is going to cause issues16:34
sf-slack<kgugala> yep17:11
sf-slack<kgugala> mitrho: and I think I found the place where we're hit by the multiple chain issue17:12
sf-slack<kgugala> here
tpbTitle: vtr-verilog-to-routing/cluster.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
sf-slack<kgugala> sorry in 147117:13
litghostmkurc: There are 3 parts to splitting up the CLBs, making new tile pb_types, making a new grid, and modifying the graph import.  Which aspect are you planning on doing?17:14
sf-slack<kgugala> it checks if the molecule we're about to add is a chain, and if is, if it's root block type is the same as root block type of the logic cell to which it is going to be packed17:15
sf-slack<kgugala> in our case the root type is e.g BLK_TI-CLBLL_L17:15
sf-slack<kgugala> and the case is true for both SLICE0 and SLICE117:16
sf-slack<kgugala> of this CLB17:16
litghostkgugala: E.g. if we had 1 slice per CLB, that check would work correctly?17:16
sf-slack<kgugala> when we use first fit prepacking we ion fact have one slice with CARRY per CLB and it works17:17
sf-slack<kgugala> *in fact17:18
litghostkgugala: Right17:18
sf-slack<kgugala> I'll try to hack the packer so it will use only SLICE0 from CLBLL_L and CLBLL_R17:19
mithrolitghost: Can you ?17:27
tpbTitle: Adding DRAM file by mithro · Pull Request #403 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostmithro: Done17:27
mithrokgugala: Can't we just disable the carry-chain in everything apart from SLICE0 in CLBLL_L ?17:28
litghostmithro: No, picosoc won't fix in the ROI if you do that17:28
sf-slack<kgugala> exactly17:28
mithroDisable carry-chain generation full stop then?17:28
sf-slack<kgugala> we have this now (when using first fit)17:28
sf-slack<kgugala> mithro, litghost: the hack works (at least for the chain_pack test)17:48
sf-slack<kgugala> the chains are packed into BLK_TI-CLBLL_L.BLK_IG-SLICEL0.CARRYCHAIN and BLK_TI-CLBLL_R.BLK_IG-SLICEL0.CARRYCHAIN17:48
sf-slack<kgugala> this confirms that having two chains in one CLB is causing the problems17:49
sf-slack<kgugala> in my test i have two 8-bit long counters packed into each CARRY_CHAIN17:50
sf-slack<kgugala> but I use only SLICE0 from CLB's17:50
sf-slack<kgugala> and the hack is really ugly ;)17:51
litghostkgugala: We should be able to do the equivilant of the hack by simply modifying the pb_types17:51
sf-slack<kgugala> sure17:52
sf-slack<kgugala> because the hack is:17:52
sf-slack<kgugala> ```17:52
sf-slack<kgugala> + /* XXX: hack */ + if((pattern == 5 || pattern == 7 || pattern == 8 || (pattern >= 17 && pattern <= 19)) feasible_patterns[pattern] = false;17:52
litghostkgugala:  In the long term splitting the CLB's into two is the right solution, but in the short term disabling the second chain on each CLBLL and disabling the M chain in the CLBLM will get 1/2 of the carry chains working, rather than 1/817:57
litghostAt 1/2 carry chains working, picosoc will likely fit17:57
litghostOnce the CLB split is dont, we'll have 3/4 of the chains working, and would just need to solve the SLICE_M issue17:57
sf-slack<kgugala> I agree17:58
sf-slack<kgugala> but we should modify the CC specializer script, rather than use the above hack17:59
mithroI will be chatting with the vtr devs today about the idea of equivalent blocks17:59
*** acomodi has quit IRC18:00
sf-slack<kgugala> mithro: great, please share the outcome of the talk18:00
litghostkgugala: I agree, that is probably a good place to do it.  Do you have time to try that?  Or do you want  me to submit a PR?18:01
sf-slack<kgugala> I have to catch a flight in a about 11 hours, so I may not be able to do that today18:02
litghostkgugala: Ok, I'll take a crack at oit18:02
elmslitghost: Is there a reason to require a pb_type prefix? It looks like it stops the grid_loc prefix from being emitted, but isn't actually used:
tpbTitle: vtr-verilog-to-routing/fasm.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at
elmsI forgot I had added the prefix to get to emit, but doesn't seem correct to me. I'm cleaning up all my changes.19:21
litghostelms:  No, that code looks broken.  Does anything break when those lines are moved?19:24
elmsI'll test it out.19:24
mithrolitghost: Do you have a fasm output from vpr around somewhere?20:21
litghostmithro: Sure why?20:22
litghostmithro: Want a paste?20:22
mithrolitghost: Sure20:22
mithrolitghost: Actually, it would be good if it was just a wire example20:22
litghostmithro: You mean pip?20:22
mithrolitghost: I mean a simple design which only has a single trace between IO or something20:23
sf-slack<mkurc> @litghost Regarding the CLB split - I know how to do new pb_types and modify the grid. In fact I've almost completed the former. Once this is done i'll have to modify the routing graph accordingly. I am doing it with a python script which modifies the final architecture desc. xml.20:23
litghostmkurc: Not good enough, you'll need to completely rewrite the channels20:24
litghostmkurc: The new pb_type's are the easiest part.  What's your plan for the grid?20:25
tpbTitle: top.fasm · GitHub (at
sf-slack<mkurc> @litghost: Well, I'll expand the grid horizontally and split each CLB into two adjacent element with different X coordinates. I haven't looked at the grid in detail yet. It contains not only CLBs But I think that I can do it with a script.20:28
sf-slack<mkurc> What do you mean by "rewrite channels" ?20:28
litghostmkurc: VPR requires all routing wires in the grid to be in "channels" that run in the x or y direction20:28
litghostmkurc: created channels using a grid with a 1:1 relationship20:29
litghostmkurc: If you modify the grid afterwards, the channel start/end are wrong, and you haven't formed the channels required to connect the slice furthest from the interconnect tile20:30
sf-slack<mkurc> yeah but it all is stored in the routing graph, right ?20:30
litghostmkurc: Sure, but what channels are you planning on using?20:31
litghostmkurc: Modifying the grid in the arch means that the planned channels are wrong20:31
sf-slack<mkurc> yes, i know that20:31
sf-slack<mkurc> but the graph contains nodes and connections20:31
sf-slack<mkurc> it does not care about grid or any structure20:32
litghostmkurc: Yes it does20:32
sf-slack<mkurc> so if i can split a clb to two pb_types i can do the same with the graph20:32
sf-slack<mkurc> i haven't figured out how to do it yet, but this is my idea20:32
litghostmkurc: Not really, the way that node are assigned to tiles won't work, they are tightly coupled20:33
litghostmkurc: Basically you are hand-waving all the routing graph import work, which is where the rubber meets the road so to speak20:33
sf-slack<mkurc> hmmm20:34
sf-slack<mkurc> ok, so I'will look at it tomorrow. It seems that I am missing important details.20:35
sf-slack<mkurc> I wanted to avoid modifying the whole flow (prjxray python scripts) since the CLB-based architecture is there everywhere.20:36
litghostmkurc: I don't think that is the right answer, nor the fastest route20:37
litghostmkurc: Modifying the flow (e.g. python in xc7/utils/) is the correct method, and will allow for future split site instances to be supported20:43
sf-slack<mkurc> @litghost: I know that it is the correct method but much more complicated. I thought that by doing a "patch" to the final architecture definitions I can check whether splitting CLBs will work.20:45
litghostmkurc: I doubt your "patch" will be faster than just modifying the flow20:45
sf-slack<mkurc> @litghost: Ok, I'll rethink that tomorrow. Maybe I need a deeper look into the flow architecture.20:46
*** nonlinear has quit IRC22:19
*** nonlinear has joined #symbiflow22:20

Generated by 2.13.1 by Marius Gedminas - find it at!