| *** tpb has joined #symbiflow | 00:00 | |
| *** _whitelogger has quit IRC | 01:46 | |
| *** _whitelogger has joined #symbiflow | 01:48 | |
| *** citypw has joined #symbiflow | 03:22 | |
| *** citypw has quit IRC | 03:39 | |
| *** citypw has joined #symbiflow | 03:45 | |
| *** citypw has quit IRC | 03:48 | |
| *** citypw has joined #symbiflow | 03:49 | |
| *** citypw has quit IRC | 05:19 | |
| *** citypw has joined #symbiflow | 05:28 | |
| *** OmniMancer has joined #symbiflow | 06:04 | |
| *** _whitelogger has quit IRC | 06:16 | |
| *** _whitelogger has joined #symbiflow | 06:18 | |
| *** citypw has quit IRC | 10:06 | |
| *** _whitelogger has quit IRC | 12:46 | |
| *** _whitelogger has joined #symbiflow | 12:48 | |
| *** OmniMancer has quit IRC | 12:50 | |
| 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:12 |
|---|---|---|
| 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:12 |
| *** proteusguy has joined #symbiflow | 13: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 (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:41 |
| 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:41 |
| 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 routable | 15:49 |
| sf-slack | <kgugala> I think mithro described that somwhere above | 15:50 |
| mithro | kgugala: So, looking at the architecture definition the multiple carry chains is going to cause issues | 16:34 |
| sf-slack | <kgugala> yep | 17:11 |
| sf-slack | <kgugala> mitrho: and I think I found the place where we're hit by the multiple chain issue | 17:12 |
| sf-slack | <kgugala> here https://github.com/SymbiFlow/vtr-verilog-to-routing/blob/master%2Bwip/vpr/src/pack/cluster.cpp#L1469 | 17:12 |
| tpb | Title: vtr-verilog-to-routing/cluster.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 17:12 |
| sf-slack | <kgugala> sorry in 1471 | 17:13 |
| 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: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 packed | 17:15 |
| sf-slack | <kgugala> in our case the root type is e.g BLK_TI-CLBLL_L | 17:15 |
| sf-slack | <kgugala> and the case is true for both SLICE0 and SLICE1 | 17:16 |
| sf-slack | <kgugala> of this CLB | 17:16 |
| litghost | kgugala: 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 works | 17:17 |
| sf-slack | <kgugala> *in fact | 17:18 |
| litghost | kgugala: Right | 17:18 |
| 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:27 |
| tpb | Title: Adding DRAM README.md file by mithro · Pull Request #403 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 17:27 |
| litghost | mithro: Done | 17:27 |
| mithro | kgugala: Can't we just disable the carry-chain in everything apart from SLICE0 in CLBLL_L ? | 17:28 |
| litghost | mithro: No, picosoc won't fix in the ROI if you do that | 17:28 |
| sf-slack | <kgugala> exactly | 17:28 |
| mithro | Disable 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.CARRYCHAIN | 17:48 |
| sf-slack | <kgugala> this confirms that having two chains in one CLB is causing the problems | 17:49 |
| sf-slack | <kgugala> in my test i have two 8-bit long counters packed into each CARRY_CHAIN | 17:50 |
| litghost | Cool | 17:50 |
| sf-slack | <kgugala> but I use only SLICE0 from CLB's | 17:50 |
| sf-slack | <kgugala> and the hack is really ugly ;) | 17:51 |
| litghost | kgugala: We should be able to do the equivilant of the hack by simply modifying the pb_types | 17:51 |
| sf-slack | <kgugala> sure | 17: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 |
| 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:57 |
| litghost | At 1/2 carry chains working, picosoc will likely fit | 17:57 |
| 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:57 |
| litghost | done* | 17:57 |
| sf-slack | <kgugala> I agree | 17:58 |
| sf-slack | <kgugala> but we should modify the CC specializer script, rather than use the above hack | 17:59 |
| mithro | I will be chatting with the vtr devs today about the idea of equivalent blocks | 17:59 |
| *** acomodi has quit IRC | 18:00 | |
| sf-slack | <kgugala> mithro: great, please share the outcome of the talk | 18:00 |
| 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? | 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 today | 18:02 |
| litghost | kgugala: Ok, I'll take a crack at oit | 18:02 |
| litghost | it | 18:02 |
| 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:20 |
| tpb | Title: vtr-verilog-to-routing/fasm.cpp at master+wip · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 19:20 |
| 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:21 |
| litghost | elms: No, that code looks broken. Does anything break when those lines are moved? | 19:24 |
| elms | I'll test it out. | 19:24 |
| mithro | litghost: Do you have a fasm output from vpr around somewhere? | 20:21 |
| litghost | mithro: Sure why? | 20:22 |
| litghost | mithro: Want a paste? | 20:22 |
| mithro | litghost: Sure | 20:22 |
| mithro | litghost: Actually, it would be good if it was just a wire example | 20:22 |
| litghost | mithro: You mean pip? | 20:22 |
| mithro | litghost: I mean a simple design which only has a single trace between IO or something | 20: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 |
| litghost | mkurc: Not good enough, you'll need to completely rewrite the channels | 20:24 |
| litghost | mkurc: The new pb_type's are the easiest part. What's your plan for the grid? | 20:25 |
| litghost | mithro: https://gist.github.com/litghost/e807b0085a49151defaf4f0cefc08f1c | 20:26 |
| tpb | Title: top.fasm · GitHub (at gist.github.com) | 20:26 |
| 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 |
| litghost | mkurc: VPR requires all routing wires in the grid to be in "channels" that run in the x or y direction | 20:28 |
| litghost | mkurc: prjxray_form_channels.py created channels using a grid with a 1:1 relationship | 20:29 |
| 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:30 |
| sf-slack | <mkurc> yeah but it all is stored in the routing graph, right ? | 20:30 |
| litghost | mkurc: Sure, but what channels are you planning on using? | 20:31 |
| litghost | mkurc: Modifying the grid in the arch means that the planned channels are wrong | 20:31 |
| sf-slack | <mkurc> yes, i know that | 20:31 |
| sf-slack | <mkurc> but the graph contains nodes and connections | 20:31 |
| sf-slack | <mkurc> it does not care about grid or any structure | 20:32 |
| litghost | mkurc: Yes it does | 20:32 |
| sf-slack | <mkurc> so if i can split a clb to two pb_types i can do the same with the graph | 20:32 |
| sf-slack | <mkurc> i haven't figured out how to do it yet, but this is my idea | 20:32 |
| litghost | mkurc: Not really, the way that node are assigned to tiles won't work, they are tightly coupled | 20:33 |
| 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:33 |
| sf-slack | <mkurc> hmmm | 20: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 |
| litghost | mkurc: I don't think that is the right answer, nor the fastest route | 20:37 |
| 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: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 |
| litghost | mkurc: I doubt your "patch" will be faster than just modifying the flow | 20: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 IRC | 22:19 | |
| *** nonlinear has joined #symbiflow | 22:20 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!