Thursday, 2019-04-11

*** tpb has joined #symbiflow00:00
*** proteusguy has quit IRC00:19
*** proteusguy has joined #symbiflow00:31
*** sf-slack2 has joined #symbiflow00:37
*** sf-slack has quit IRC00:40
*** adjtm_ has quit IRC00:40
*** adjtm has joined #symbiflow00:40
*** futarisIRCcloud has joined #symbiflow02:27
*** Bertl_oO is now known as Bertl_zZ03:53
*** nrossi has joined #symbiflow04:13
*** futarisIRCcloud has quit IRC05:07
*** futarisIRCcloud has joined #symbiflow05:26
*** OmniMancer has joined #symbiflow06:48
*** GuzTech has joined #symbiflow07:54
*** futarisIRCcloud has quit IRC08:17
*** proteusguy has quit IRC08:22
*** Bertl_zZ is now known as Bertl12:01
sf-slack2<acomodi> litghost, mithro: when you have some time, could you look at this on tile equivalence? Before proceeding with the other placer changes it would be good to check whether I am going into the right direction12:06
tpbTitle: WIP: Equivalent tiles VTR feature by acomodi · Pull Request #36 · SymbiFlow/vtr-verilog-to-routing · GitHub (at
*** nrossi has quit IRC12:18
*** xobs has quit IRC12:19
*** zeigren has quit IRC12:19
*** galv[m] has quit IRC12:19
*** mrhat2010[m] has quit IRC12: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
litghostmkurc: Okay, that matches what happened when I first connected the constant network14:16
tpbTitle: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostmkurc: I suggest filing a bug against VPR and talking to kem_ over in #vtr-dev14:18
*** rvalles has joined #symbiflow14:18
litghostmkurc: Do follow kem_'s suggestion in to enable routing debug14:19
tpbTitle: Routing failure on global channel structure · Issue #520 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostmkurc: kem_ did submit a fix for the constant routing that was require, but unclear if that is what is going on14:19
litghostmkurc: All you did was shift the entire grid, yes?14:20
litghostWeird :|14:20
sf-slack2<mkurc> @litghost Yes what i did was shfit the grid 2 tiles to the right.14:20
litghostmkurc: It's very confusing why that would break things, we must be missing something14:21
litghostmkurc: The details routing output might provide a hint14:21
litghostmkurc: 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 suggestion14: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 new14:25
litghostmkurc: Definitely take a look at the detailed routing output, something must be different :(14:25
*** GuzTech has quit IRC14:49
*** citypw has joined #symbiflow14:59
*** tux3 has quit IRC15:34
*** tux3 has joined #symbiflow15:34
*** citypw has quit IRC16:29
*** OmniMancer has quit IRC16:39
litghostFYI , this probably explains the excessive runtimes when using the conda build of VTR18:06
tpbTitle: VPR being compiled without thread support · Issue #14 · SymbiFlow/conda-packages · GitHub (at
*** proteusguy has joined #symbiflow19:29
elmsthat explains what hzeller was seeing on build times as well19:52
litghostelms: Yep!19:55
*** lopsided98 has quit IRC20:10
*** lopsided98 has joined #symbiflow20:11
*** Bertl is now known as Bertl_oO20:12
hackerfoolitghost: DLUT can't be used for dual port RAM, right?21:04
tpbTitle: RAM64X1D.fasm · GitHub (at
hackerfooThat's from Vivado.21:05
litghostthe DLUT cannot be the DPO, it must be the SPO21:06
litghostEach of the other BLUT can be either DPO or SPO21:08
litghostSorry, let me try again21:08
litghostCLUT and ALUT are either DPO and SPO21:08
mithrolitghost: You know that you can enable travis on your own repositories?21:08
litghostBLUT is SPO when ALUT/BLUT are in RAM64X1D21:10
hackerfoolitghost: Okay, so it just needs to be paired with a CLUT.21:10
litghosthackerfoo: Ya21:11
litghosthackerfoo: dual port DRAM's are always two LUT's21:11
litghosthackerfoo: Maybe more21:11
litghosthackerfoo: RAM128X1D is 2 SPO luts and 2 DPO luts21:12
litghosthackerfoo: reduced with the MUXF7's21:12
litghosthackerfoo: Something I've realized in the AI/BI/CI bit is truelly a mux control21:12
litghosthackerfoo: The SPO vs DPO has to do with how the address lines are wires21:13
litghosthackerfoo: wired21:13
litghosthackerfoo: SPO simply means DPRA == A21:13
hackerfooSo you can write one address and read another, or read two at once.21:14
litghosthackerfoo: Right21:14
litghosthackerfoo: So a dual port DRAM has a single port and dual port DRAM21:14
litghosthackerfoo: In the case of a 64X1D that is generally DLUT/CLUT or BLUT/ALUT21:14
litghosthackerfoo: I expected that 32X1D would be similiar, but I haven't tested it21:15
litghosthackerfoo: Is from a RAM64X1D or something else?21:17
tpbTitle: RAM64X1D.fasm · GitHub (at
hackerfooIt's the 2 RAM64X1D design you sent me.21:18
litghosthackerfoo: Right, ya that makes sense to me21:19
litghosthackerfoo: And it is the FASM model I implemented in the arch def, plus handling the BI mux for the BLUT/ALUT pair21:19
hackerfooI'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
litghosthackerfoo: I tend to agree with you21:20
hackerfooOr low. I can't remember.21:20
litghosthackerfoo: I think the useful thing is something akin to a 32X2D21:20
litghosthackerfoo: But that doesn't appear explicitly21:20
litghosthackerfoo: Anyways, if you are correct that a 32X1D is just a 64X1D with lines tied, then that is a super simple tech map fix21:21
tpbTitle: symbiflow-arch-defs/cells_map.v at master · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghosthackerfoo: 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 Yosys21:22
litghosthackerfoo: However there is not reason not to support the primative, in case someone used one in their design21:22
hackerfooI'm guessing that it makes routing easier by not connecting those two address pins.21:23
litghosthackerfoo: Another option to consider is to tech map the RAM32X1D to the RAM64X1D and let yosys further techmap down to the our VPR primatives21:23
litghosthackerfoo: 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 hardware21:23
hackerfooHere's RAM32X1D:
tpbTitle: RAM32X1D.fasm · GitHub (at
hackerfooThe only difference is that the SMALL features are set.21:35
litghosthackerfoo: Okay, that is the model I expected, and what I intended VPR to do21:35
litghosthackerfoo: Does the VPR output behave like that?21:36
hackerfooI'm going to check that next.21:36
litghosthackerfoo: Okay, sounds good21:36
*** futarisIRCcloud has joined #symbiflow21:46
hackerfooRAM32X1D from VPR:
tpbTitle: RAM32X1D_vpr.fasm · GitHub (at
hackerfooRAM64X1D from VPR:
tpbTitle: RAM64X1D_vpr.fasm · GitHub (at
hackerfooWhat's DI1MUX.BI?21:52
hackerfooSo BI is muxed into BLUT, and this is different.21:54
litghosthackerfoo: It controls the DI1 mux21:54
litghosthackerfoo: 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 same21:55
litghosthackerfoo: VPR doesn't currently have a perfect model of the DI muxes, so it uses two DI wires rather than 121:55
mithroelms: Did you see ?22:05
tpbTitle: WIP [DNM]: generate arch.xml from verilog templates including timing info by kgugala · Pull Request #574 · SymbiFlow/symbiflow-arch-defs · GitHub (at
elmsmithro: yeah thanks for making sure though. I pulled it down and think I'll add some comments.22:08
mithroelms: So, we have xc7/primitives/common_slice/Nlut/simtest/test_alut.py22:10
mithroelms: I assume we are not running that test on CI in any way at the moment?22:10
hackerfooI changed the D input for the second RAM32X1D and Vivado added {C,D}OUTMUX.O5, but not any DI1MUX.22:13
hackerfooI'm not sure why BI would be used; doesn't the data (D) get connected to DI?22:14
litghosthackerfoo: Is Vivado packing the the two RAM32X1D's into the same SLICE?22:16
hackerfooNo, Vivado isn't. VPR is.22:17
litghosthackerfoo: In order to do that the write address lines, write enable, read address lines must be the smae22:17
hackerfooOkay, I get one slice, but no BI:
tpbTitle: RAM32X1D_vivado_1slice.v · GitHub (at
hackerfoo(from Vivado)22:23
hackerfooThat must be interpreted incorrectly, or BI is being enabled implicitly?22:24
litghostHold on a minute22:28
litghostThat FASM output only has 2 RAM instances22:29
litghostIs the RAM32X1D located in just one LUT?22:29
litghostWith O5 as DPO/SPO and O6 as the other?22:29
litghostThat is a significant different22:29
litghostAnd not what I modelled22:29
hackerfooThat seems to contradict the datasheet.22:30
hackerfooBut there's not much information on 32X1D. It just says it takes 2 LUTs.22:32
litghosthackerfoo: Okay. Check the routing resources display on the Vivado output and see what is the actually placement22:32
litghosthackerfoo: E.g. Where is the SPO and DPO lines?22:33
elmsmithro: I discovered those tests when I started looking reorganizing the code. Currently I think CI only runs on top level utils/22:36
mithroelms: Yeah22:36
mithrohackerfoo: So I started thinking about the idea of having a "library" of flipflop objects in symbiflow-arch-defs which we map the Xilinx primitives to23:01
tpbTitle: Yosys Primitives to VPR Mapping - Google Docs (at
mithrohackerfoo: Yosys actually already has a pretty exhaustive set of flipflop types23:01
mithroalso started coming out of elms' quest to map various terms to each other
tpbTitle: SymbiFlow Name Mapping (Xilinx, Lattice, Altera/Intel) - Google Sheets (at
*** adjtm has quit IRC23:29
*** Vonter has quit IRC23:29
*** kgugala has quit IRC23:29
litghostCall out if someone wants to help with xc7 fasm2verilog support:
tpbTitle: Improve xc7 fasm2verilog output · Issue #578 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostWe have something that is functional, but the net names are pretty unhelpful, soley based on the underlying BEL23:35
*** adjtm has joined #symbiflow23:35
*** Vonter has joined #symbiflow23:35
*** kgugala has joined #symbiflow23:35
litghostWould be nice if we could better annotate the net names based on the VPR net name23:35
litghostAlong with some carry chain beutification23:36
* hackerfoo posted a file: dram.jpg (163KB) < >23:52
hackerfooBoth RAM32X1Ds seem to map to those same two LUTs.23:53
litghosthackerfoo: Which lines are the SPO and DPO?23:53
litghosthackerfoo: I think what is happening is that RAM + SMALL makes two RAM32 instances per LUT23:54
litghosthackerfoo: You were asking why RAM32X1D, well you can pack 2 RAM32X1D per LUT pair23:54
litghosthackerfoo: Assuming I'm reading what is happening correctly23:55
litghosthackerfoo: The key is thinking about a LUT6 as really just two LUT5's with a mux at the output23:55
hackerfooAh, so 1 takes 2 LUTs, but you can fit a second one in for free?23:55
litghosthackerfoo: That's the theory23:56
litghosthackerfoo: If that is correct, then the two outputs on the top LUT should be inst1.SPO and inst2.SPO23:56
litghosthackerfoo: Checkout LUT6_2 in the 7-series library23:57
litghosthackerfoo: It has diagram that is pretty useful23:57
litghosthackerfoo: If I5 is tied high, then the two LUT5 instances can be considered indepedent23:57
hackerfooSPOs are O5/6 from DLUT, and DPOs are from CLUT.23:59
litghosthackerfoo: Yep, that matches the theory23:59

Generated by 2.13.1 by Marius Gedminas - find it at!