| *** tpb has joined #symbiflow | 00:00 | |
| *** proteusguy has quit IRC | 00:19 | |
| *** proteusguy has joined #symbiflow | 00:31 | |
| *** sf-slack2 has joined #symbiflow | 00:37 | |
| *** sf-slack has quit IRC | 00:40 | |
| *** adjtm_ has quit IRC | 00:40 | |
| *** adjtm has joined #symbiflow | 00:40 | |
| *** futarisIRCcloud has joined #symbiflow | 02:27 | |
| *** Bertl_oO is now known as Bertl_zZ | 03:53 | |
| *** nrossi has joined #symbiflow | 04:13 | |
| *** futarisIRCcloud has quit IRC | 05:07 | |
| *** futarisIRCcloud has joined #symbiflow | 05:26 | |
| *** OmniMancer has joined #symbiflow | 06:48 | |
| *** GuzTech has joined #symbiflow | 07:54 | |
| *** futarisIRCcloud has quit IRC | 08:17 | |
| *** proteusguy has quit IRC | 08:22 | |
| *** Bertl_zZ is now known as Bertl | 12:01 | |
| sf-slack2 | <acomodi> litghost, mithro: when you have some time, could you look at this https://github.com/SymbiFlow/vtr-verilog-to-routing/pull/36 on tile equivalence? Before proceeding with the other placer changes it would be good to check whether I am going into the right direction | 12:06 |
|---|---|---|
| tpb | Title: WIP: Equivalent tiles VTR feature by acomodi · Pull Request #36 · SymbiFlow/vtr-verilog-to-routing · GitHub (at github.com) | 12:06 |
| *** nrossi has quit IRC | 12:18 | |
| *** xobs has quit IRC | 12:19 | |
| *** zeigren has quit IRC | 12:19 | |
| *** galv[m] has quit IRC | 12:19 | |
| *** mrhat2010[m] has quit IRC | 12:20 | |
| sf-slack2 | <mkurc> @litghost I created a tool to traverse rr graph which allows to verify if a connection between two nodes is possible. And I verified that there is a possibility of connection between the SOURCE in the BLK_SY-GND and a CLB tile despite that the VPR throws an error. I checked using node indices as included in the error message. | 13:19 |
| sf-slack2 | <mkurc> The tool only cares only about node indices and edge to node indices. It does not check channel location and directions nor IPIN and OPIN directions. | 13:21 |
| sf-slack2 | <mkurc> BTW the graph traversal tool is still a WIP. I will be able to push it tomorrow. | 13:32 |
| litghost | mkurc: Okay, that matches what happened when I first connected the constant network | 14:16 |
| litghost | mkurc: https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/520 | 14:18 |
| tpb | Title: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 14:18 |
| litghost | mkurc: I suggest filing a bug against VPR and talking to kem_ over in #vtr-dev | 14:18 |
| *** rvalles has joined #symbiflow | 14:18 | |
| litghost | mkurc: Do follow kem_'s suggestion in https://github.com/verilog-to-routing/vtr-verilog-to-routing/issues/520#issuecomment-478057904 to enable routing debug | 14:19 |
| tpb | Title: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 14:19 |
| litghost | mkurc: kem_ did submit a fix for the constant routing that was require, but unclear if that is what is going on | 14:19 |
| litghost | mkurc: All you did was shift the entire grid, yes? | 14:20 |
| litghost | Weird :| | 14:20 |
| sf-slack2 | <mkurc> @litghost Yes what i did was shfit the grid 2 tiles to the right. | 14:20 |
| litghost | mkurc: It's very confusing why that would break things, we must be missing something | 14:21 |
| litghost | mkurc: The details routing output might provide a hint | 14:21 |
| litghost | mkurc: I might finish up the FF CE/SR changes today, so I can dig into what is going on with your PR. Any new commits on the PR that haven't been pushed? | 14:22 |
| sf-slack2 | <mkurc> Though I am not 100% sure whether the grid shift implementation is correct. Lets say I am 99.9% sure that it is correct. | 14:22 |
| sf-slack2 | <mkurc> I will try with the kem's suggestion | 14:23 |
| sf-slack2 | <mkurc> Actually what is weird is when i shift the grid to the east I got an error but when I shift to the north I got no error... | 14:24 |
| sf-slack2 | <mkurc> @litghost I didn't push anything new | 14:25 |
| litghost | mkurc: Definitely take a look at the detailed routing output, something must be different :( | 14:25 |
| *** GuzTech has quit IRC | 14:49 | |
| *** citypw has joined #symbiflow | 14:59 | |
| *** tux3 has quit IRC | 15:34 | |
| *** tux3 has joined #symbiflow | 15:34 | |
| *** citypw has quit IRC | 16:29 | |
| *** OmniMancer has quit IRC | 16:39 | |
| litghost | FYI https://github.com/SymbiFlow/conda-packages/issues/14 , this probably explains the excessive runtimes when using the conda build of VTR | 18:06 |
| tpb | Title: VPR being compiled without thread support · Issue #14 · SymbiFlow/conda-packages · GitHub (at github.com) | 18:06 |
| *** proteusguy has joined #symbiflow | 19:29 | |
| elms | that explains what hzeller was seeing on build times as well | 19:52 |
| litghost | elms: Yep! | 19:55 |
| *** lopsided98 has quit IRC | 20:10 | |
| *** lopsided98 has joined #symbiflow | 20:11 | |
| *** Bertl is now known as Bertl_oO | 20:12 | |
| hackerfoo | litghost: DLUT can't be used for dual port RAM, right? | 21:04 |
| hackerfoo | https://gist.github.com/HackerFoo/1d54628ed8ad54fa16d356604af6842b | 21:04 |
| tpb | Title: RAM64X1D.fasm · GitHub (at gist.github.com) | 21:04 |
| hackerfoo | That's from Vivado. | 21:05 |
| litghost | Correct | 21:06 |
| litghost | Kindof | 21:06 |
| litghost | the DLUT cannot be the DPO, it must be the SPO | 21:06 |
| litghost | Each of the other BLUT can be either DPO or SPO | 21:08 |
| litghost | Sorry, let me try again | 21:08 |
| litghost | CLUT and ALUT are either DPO and SPO | 21:08 |
| mithro | litghost: You know that you can enable travis on your own repositories? | 21:08 |
| litghost | BLUT is SPO when ALUT/BLUT are in RAM64X1D | 21:10 |
| hackerfoo | litghost: Okay, so it just needs to be paired with a CLUT. | 21:10 |
| litghost | hackerfoo: Ya | 21:11 |
| litghost | hackerfoo: dual port DRAM's are always two LUT's | 21:11 |
| litghost | hackerfoo: Maybe more | 21:11 |
| litghost | hackerfoo: RAM128X1D is 2 SPO luts and 2 DPO luts | 21:12 |
| litghost | hackerfoo: reduced with the MUXF7's | 21:12 |
| litghost | hackerfoo: Something I've realized in the AI/BI/CI bit is truelly a mux control | 21:12 |
| litghost | hackerfoo: The SPO vs DPO has to do with how the address lines are wires | 21:13 |
| litghost | hackerfoo: wired | 21:13 |
| litghost | hackerfoo: SPO simply means DPRA == A | 21:13 |
| hackerfoo | So you can write one address and read another, or read two at once. | 21:14 |
| litghost | hackerfoo: Right | 21:14 |
| litghost | hackerfoo: So a dual port DRAM has a single port and dual port DRAM | 21:14 |
| litghost | hackerfoo: In the case of a 64X1D that is generally DLUT/CLUT or BLUT/ALUT | 21:14 |
| litghost | hackerfoo: I expected that 32X1D would be similiar, but I haven't tested it | 21:15 |
| litghost | hackerfoo: Is https://gist.github.com/HackerFoo/1d54628ed8ad54fa16d356604af6842b from a RAM64X1D or something else? | 21:17 |
| tpb | Title: RAM64X1D.fasm · GitHub (at gist.github.com) | 21:17 |
| hackerfoo | It's the 2 RAM64X1D design you sent me. | 21:18 |
| litghost | hackerfoo: Right, ya that makes sense to me | 21:19 |
| litghost | hackerfoo: And it is the FASM model I implemented in the arch def, plus handling the BI mux for the BLUT/ALUT pair | 21:19 |
| hackerfoo | I'm not sure what the point of 32X1D is. As far as I can tell, it's the same as 64X1D but with the two high address inputs high. | 21:20 |
| litghost | hackerfoo: I tend to agree with you | 21:20 |
| hackerfoo | Or low. I can't remember. | 21:20 |
| litghost | hackerfoo: I think the useful thing is something akin to a 32X2D | 21:20 |
| litghost | hackerfoo: But that doesn't appear explicitly | 21:20 |
| litghost | hackerfoo: Anyways, if you are correct that a 32X1D is just a 64X1D with lines tied, then that is a super simple tech map fix | 21:21 |
| litghost | https://github.com/SymbiFlow/symbiflow-arch-defs/blob/master/xc7/techmap/cells_map.v#L352 | 21:21 |
| tpb | Title: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 21:21 |
| litghost | hackerfoo: And if you are correct that there isn't a reason to use it, then there is no need to add back RAM32X1D synthesis to Yosys | 21:22 |
| litghost | hackerfoo: However there is not reason not to support the primative, in case someone used one in their design | 21:22 |
| hackerfoo | I'm guessing that it makes routing easier by not connecting those two address pins. | 21:23 |
| litghost | hackerfoo: Another option to consider is to tech map the RAM32X1D to the RAM64X1D and let yosys further techmap down to the our VPR primatives | 21:23 |
| litghost | hackerfoo: Sure, but yosys would've tied the pins to VCC anyways, and VCC ties on those lines are "free" and the default state of the hardware | 21:23 |
| hackerfoo | Here's RAM32X1D: https://gist.github.com/HackerFoo/eeb8f6bb573effe3832bca5ce41a0bb1 | 21:34 |
| tpb | Title: RAM32X1D.fasm · GitHub (at gist.github.com) | 21:34 |
| hackerfoo | The only difference is that the SMALL features are set. | 21:35 |
| litghost | hackerfoo: Okay, that is the model I expected, and what I intended VPR to do | 21:35 |
| litghost | hackerfoo: Does the VPR output behave like that? | 21:36 |
| hackerfoo | I'm going to check that next. | 21:36 |
| litghost | hackerfoo: Okay, sounds good | 21:36 |
| *** futarisIRCcloud has joined #symbiflow | 21:46 | |
| hackerfoo | RAM32X1D from VPR: https://gist.github.com/HackerFoo/b3749fbc72e2f43419e1fdbd21dbed7e | 21:51 |
| tpb | Title: RAM32X1D_vpr.fasm · GitHub (at gist.github.com) | 21:51 |
| hackerfoo | RAM64X1D from VPR: https://gist.github.com/HackerFoo/80167a833ac8475863bd704503f45a9b | 21:51 |
| tpb | Title: RAM64X1D_vpr.fasm · GitHub (at gist.github.com) | 21:51 |
| hackerfoo | What's DI1MUX.BI? | 21:52 |
| hackerfoo | So BI is muxed into BLUT, and this is different. | 21:54 |
| litghost | hackerfoo: It controls the DI1 mux | 21:54 |
| litghost | hackerfoo: I don't think that is the problem. If you want to see vivado make that output, change the DI signals to not be the same | 21:55 |
| litghost | hackerfoo: VPR doesn't currently have a perfect model of the DI muxes, so it uses two DI wires rather than 1 | 21:55 |
| mithro | elms: Did you see https://github.com/SymbiFlow/symbiflow-arch-defs/pull/574 ? | 22:05 |
| tpb | Title: WIP [DNM]: generate arch.xml from verilog templates including timing info by kgugala · Pull Request #574 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 22:05 |
| elms | mithro: yeah thanks for making sure though. I pulled it down and think I'll add some comments. | 22:08 |
| mithro | elms: So, we have xc7/primitives/common_slice/Nlut/simtest/test_alut.py | 22:10 |
| mithro | elms: I assume we are not running that test on CI in any way at the moment? | 22:10 |
| hackerfoo | I changed the D input for the second RAM32X1D and Vivado added {C,D}OUTMUX.O5, but not any DI1MUX. | 22:13 |
| hackerfoo | I'm not sure why BI would be used; doesn't the data (D) get connected to DI? | 22:14 |
| litghost | hackerfoo: Is Vivado packing the the two RAM32X1D's into the same SLICE? | 22:16 |
| hackerfoo | No, Vivado isn't. VPR is. | 22:17 |
| litghost | hackerfoo: In order to do that the write address lines, write enable, read address lines must be the smae | 22:17 |
| hackerfoo | Okay, I get one slice, but no BI: https://gist.github.com/HackerFoo/96785e5de287891b06d94f8ecdc6c0b7 | 22:23 |
| tpb | Title: RAM32X1D_vivado_1slice.v · GitHub (at gist.github.com) | 22:23 |
| hackerfoo | (from Vivado) | 22:23 |
| hackerfoo | That must be interpreted incorrectly, or BI is being enabled implicitly? | 22:24 |
| litghost | Hold on a minute | 22:28 |
| litghost | That FASM output only has 2 RAM instances | 22:29 |
| litghost | Is the RAM32X1D located in just one LUT? | 22:29 |
| litghost | With O5 as DPO/SPO and O6 as the other? | 22:29 |
| litghost | That is a significant different | 22:29 |
| litghost | And not what I modelled | 22:29 |
| hackerfoo | That seems to contradict the datasheet. | 22:30 |
| hackerfoo | But there's not much information on 32X1D. It just says it takes 2 LUTs. | 22:32 |
| litghost | hackerfoo: Okay. Check the routing resources display on the Vivado output and see what is the actually placement | 22:32 |
| litghost | hackerfoo: E.g. Where is the SPO and DPO lines? | 22:33 |
| elms | mithro: I discovered those tests when I started looking reorganizing the code. Currently I think CI only runs on top level utils/ | 22:36 |
| mithro | elms: Yeah | 22:36 |
| mithro | hackerfoo: So I started thinking about the idea of having a "library" of flipflop objects in symbiflow-arch-defs which we map the Xilinx primitives to | 23:01 |
| mithro | hackerfoo: https://docs.google.com/document/d/1g9IH5AXonvVO0WTov9BkFI-WFyIt5x33908-l_uB-S4/edit | 23:01 |
| tpb | Title: Yosys Primitives to VPR Mapping - Google Docs (at docs.google.com) | 23:01 |
| mithro | hackerfoo: Yosys actually already has a pretty exhaustive set of flipflop types | 23:01 |
| mithro | also started coming out of elms' quest to map various terms to each other https://docs.google.com/spreadsheets/d/1pWjU8RujiGdlr-8iG66O1rvognNHgtnNVvCjSfksH-4/edit#gid=0 | 23:02 |
| tpb | Title: SymbiFlow Name Mapping (Xilinx, Lattice, Altera/Intel) - Google Sheets (at docs.google.com) | 23:02 |
| *** adjtm has quit IRC | 23:29 | |
| *** Vonter has quit IRC | 23:29 | |
| *** kgugala has quit IRC | 23:29 | |
| litghost | Call out if someone wants to help with xc7 fasm2verilog support: https://github.com/SymbiFlow/symbiflow-arch-defs/issues/578 | 23:35 |
| tpb | Title: Improve xc7 fasm2verilog output · Issue #578 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 23:35 |
| litghost | We have something that is functional, but the net names are pretty unhelpful, soley based on the underlying BEL | 23:35 |
| *** adjtm has joined #symbiflow | 23:35 | |
| *** Vonter has joined #symbiflow | 23:35 | |
| *** kgugala has joined #symbiflow | 23:35 | |
| litghost | Would be nice if we could better annotate the net names based on the VPR net name | 23:35 |
| litghost | Along with some carry chain beutification | 23:36 |
| * hackerfoo posted a file: dram.jpg (163KB) < http://sandbox.hackerfoo.com:8008/_matrix/media/v1/download/sandbox.hackerfoo.com/xlrePFypxxeopVfLLCXTUGrx > | 23:52 | |
| hackerfoo | Both RAM32X1Ds seem to map to those same two LUTs. | 23:53 |
| litghost | hackerfoo: Which lines are the SPO and DPO? | 23:53 |
| litghost | hackerfoo: I think what is happening is that RAM + SMALL makes two RAM32 instances per LUT | 23:54 |
| litghost | hackerfoo: You were asking why RAM32X1D, well you can pack 2 RAM32X1D per LUT pair | 23:54 |
| litghost | hackerfoo: Assuming I'm reading what is happening correctly | 23:55 |
| litghost | hackerfoo: The key is thinking about a LUT6 as really just two LUT5's with a mux at the output | 23:55 |
| hackerfoo | Ah, so 1 takes 2 LUTs, but you can fit a second one in for free? | 23:55 |
| litghost | hackerfoo: That's the theory | 23:56 |
| litghost | hackerfoo: If that is correct, then the two outputs on the top LUT should be inst1.SPO and inst2.SPO | 23:56 |
| litghost | hackerfoo: Checkout LUT6_2 in the 7-series library | 23:57 |
| litghost | hackerfoo: It has diagram that is pretty useful | 23:57 |
| litghost | hackerfoo: If I5 is tied high, then the two LUT5 instances can be considered indepedent | 23:57 |
| hackerfoo | SPOs are O5/6 from DLUT, and DPOs are from CLUT. | 23:59 |
| litghost | hackerfoo: Yep, that matches the theory | 23:59 |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!