13:05 <sf-slack> <acomodi> Hi, I have been making progress on the slicem issue and made a PR (https://github.com/SymbiFlow/symbiflow-arch-defs/pull/402) that should be able to solve the problem. Further explanations of my findings can be seen in the PR itself

13:05 <tpb> Title: d_dram.pb_type: update xml definition to solve slicem issue by acomodi · Pull Request #402 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

13:29 <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:33 <sf-slack> <tmichalak> Hi Guys, I am still struggling with the placer issue for the carry chains (https://github.com/SymbiFlow/vtr-verilog-to-routing/issues/8). The architecture XMLs seem to be in order, hence the bug must be somewhere in the clustering part...

13:33 <tpb> Title: Placer cannot handle slice_l and slice_r carry chains in the same CLB · Issue #8 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

13:36 <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.

15:42 <sf-slack> <kgugala> @mkurc yes, it tries to pack a molecule and then it checks if the packing is routable

15:43 <sf-slack> <kgugala> I think mithro described that somwhere above

16:27 <mithro> kgugala: So, looking at the architecture definition the multiple carry chains is going to cause issues

17:03 <sf-slack> <kgugala> yep

17:05 <sf-slack> <kgugala> mitrho: and I think I found the place where we're hit by the multiple chain issue

17:05 <sf-slack> <kgugala> here https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/pack/cluster.cpp#L1469

17:05 <tpb> Title: vtr-verilog-to-routing/cluster.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

17:05 <sf-slack> <kgugala> sorry in 1471

17:07 <litghost> mkurc: 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:08 <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 packed

17:08 <sf-slack> <kgugala> in our case the root type is e.g BLK_TI-CLBLL_L

17:08 <sf-slack> <kgugala> and the case is true for both SLICE0 and SLICE1

17:09 <sf-slack> <kgugala> of this CLB

17:09 <litghost> kgugala: E.g. if we had 1 slice per CLB, that check would work correctly?

17:10 <sf-slack> <kgugala> when we use first fit prepacking we ion fact have one slice with CARRY per CLB and it works

17:10 <sf-slack> <kgugala> *in fact

17:11 <litghost> kgugala: Right

17:11 <sf-slack> <kgugala> I'll try to hack the packer so it will use only SLICE0 from CLBLL_L and CLBLL_R

17:19 <mithro> litghost: Can you https://github.com/SymbiFlow/symbiflow-arch-defs/pull/403 ?

17:20 <tpb> Title: Adding DRAM README.md file by mithro · Pull Request #403 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)

17:20 <litghost> mithro: Done

17:20 <mithro> kgugala: Can't we just disable the carry-chain in everything apart from SLICE0 in CLBLL_L ?

17:20 <litghost> mithro: No, picosoc won't fix in the ROI if you do that

17:21 <sf-slack> <kgugala> exactly

17:21 <mithro> Disable carry-chain generation full stop then?

17:21 <sf-slack> <kgugala> we have this now (when using first fit)

17:40 <sf-slack> <kgugala> mithro, litghost: the hack works (at least for the chain_pack test)

17:41 <sf-slack> <kgugala> the chains are packed into BLK_TI-CLBLL_L.BLK_IG-SLICEL0.CARRYCHAIN and BLK_TI-CLBLL_R.BLK_IG-SLICEL0.CARRYCHAIN

17:41 <sf-slack> <kgugala> this confirms that having two chains in one CLB is causing the problems

17:43 <sf-slack> <kgugala> in my test i have two 8-bit long counters packed into each CARRY_CHAIN

17:43 <litghost> Cool

17:43 <sf-slack> <kgugala> but I use only SLICE0 from CLB's

17:43 <sf-slack> <kgugala> and the hack is really ugly ;)

17:44 <litghost> kgugala: We should be able to do the equivilant of the hack by simply modifying the pb_types

17:44 <sf-slack> <kgugala> sure

17:45 <sf-slack> <kgugala> because the hack is:

17:45 <sf-slack> <kgugala> ```

17:45 <sf-slack> <kgugala> + /* XXX: hack */ + if((pattern == 5 || pattern == 7 || pattern == 8 || (pattern >= 17 && pattern <= 19)) feasible_patterns[pattern] = false;

17:49 <litghost> kgugala: 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/8

17:49 <litghost> At 1/2 carry chains working, picosoc will likely fit

17:50 <litghost> Once the CLB split is dont, we'll have 3/4 of the chains working, and would just need to solve the SLICE_M issue

17:50 <litghost> done*

17:51 <sf-slack> <kgugala> I agree

17:52 <sf-slack> <kgugala> but we should modify the CC specializer script, rather than use the above hack

17:52 <mithro> I will be chatting with the vtr devs today about the idea of equivalent blocks

17:53 <sf-slack> <kgugala> mithro: great, please share the outcome of the talk

17:53 <litghost> kgugala: 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?

17:54 <sf-slack> <kgugala> I have to catch a flight in a about 11 hours, so I may not be able to do that today

17:55 <litghost> kgugala: Ok, I'll take a crack at oit

17:55 <litghost> it

19:13 <elms> litghost: 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: https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/utils/fasm/src/fasm.cpp#L62-L67

19:13 <tpb> Title: vtr-verilog-to-routing/fasm.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com)

19:14 <elms> I 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:16 <litghost> elms: No, that code looks broken. Does anything break when those lines are moved?

19:17 <elms> I'll test it out.

20:14 <mithro> litghost: Do you have a fasm output from vpr around somewhere?

20:14 <litghost> mithro: Sure why?

20:14 <litghost> mithro: Want a paste?

20:14 <mithro> litghost: Sure

20:15 <mithro> litghost: Actually, it would be good if it was just a wire example

20:15 <litghost> mithro: You mean pip?

20:16 <mithro> litghost: I mean a simple design which only has a single trace between IO or something

20:16 <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:17 <litghost> mkurc: Not good enough, you'll need to completely rewrite the channels

20:17 <litghost> mkurc: The new pb_type's are the easiest part. What's your plan for the grid?

20:19 <litghost> mithro: https://gist.github.com/litghost/e807b0085a49151defaf4f0cefc08f1c

20:19 <tpb> Title: top.fasm · GitHub (at gist.github.com)

20:20 <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:20 <sf-slack> <mkurc> What do you mean by "rewrite channels" ?

20:21 <litghost> mkurc: VPR requires all routing wires in the grid to be in "channels" that run in the x or y direction

20:21 <litghost> mkurc: prjxray_form_channels.py created channels using a grid with a 1:1 relationship

20:22 <litghost> mkurc: 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 tile

20:22 <sf-slack> <mkurc> yeah but it all is stored in the routing graph, right ?

20:23 <litghost> mkurc: Sure, but what channels are you planning on using?

20:24 <litghost> mkurc: Modifying the grid in the arch means that the planned channels are wrong

20:24 <sf-slack> <mkurc> yes, i know that

20:24 <sf-slack> <mkurc> but the graph contains nodes and connections

20:24 <sf-slack> <mkurc> it does not care about grid or any structure

20:24 <litghost> mkurc: Yes it does

20:24 <sf-slack> <mkurc> so if i can split a clb to two pb_types i can do the same with the graph

20:25 <sf-slack> <mkurc> i haven't figured out how to do it yet, but this is my idea

20:25 <litghost> mkurc: Not really, the way that node are assigned to tiles won't work, they are tightly coupled

20:26 <litghost> mkurc: Basically you are hand-waving all the routing graph import work, which is where the rubber meets the road so to speak

20:26 <sf-slack> <mkurc> hmmm

20:27 <sf-slack> <mkurc> ok, so I'will look at it tomorrow. It seems that I am missing important details.

20:29 <sf-slack> <mkurc> I wanted to avoid modifying the whole flow (prjxray python scripts) since the CLB-based architecture is there everywhere.

20:29 <litghost> mkurc: I don't think that is the right answer, nor the fastest route

20:35 <litghost> mkurc: Modifying the flow (e.g. python in xc7/utils/) is the correct method, and will allow for future split site instances to be supported

20:37 <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:38 <litghost> mkurc: I doubt your "patch" will be faster than just modifying the flow

20:39 <sf-slack> <mkurc> @litghost: Ok, I'll rethink that tomorrow. Maybe I need a deeper look into the flow architecture.