Wednesday, 2019-04-17

*** tpb has joined #symbiflow00:00
*** Bertl_oO is now known as Bertl_zZ00:55
hackerfooHas anyone seen this error from VPR? Primitive 'FDRE_ZINI' not recognized by netlist writer01:15
hackerfooMaybe it's a flip flop that's not implemented.01:22
hackerfooI'll just comment things out until it compiles.01:23
hackerfooNevermind. I got it to work.01:40
mithroBlack box image so far...
hackerfooCheck it out, I made a memory tester. It works, even:
tpbTitle: mem_tester.v · GitHub (at
hackerfooIt reads and writes from a shift register (from switches to leds) and uses the dual port ram as a double buffer, so flipping SW0 swaps the pages.01:58
mithroI don't understand why netlistsvg is choosing such a bad position for the DLUT and other similar parts01:59
hackerfooD must be routed incorrectly for RAM32X1D. Even setting `.D(1'b0)` still streams out a repeating pattern of 1100 regardless of the initial contents. WE works, though, and I'm guessing the address lines work because I do get a pattern.02:13
hackerfooRAM32X1S also seems broken when using my tester. Is that expected?02:25
hackerfooRAM64X1S and RAM64X1D both work.02:25
*** citypw has joined #symbiflow03:01
mithrohackerfoo: Your big on nix stuff right? Might want to checkout
tpbTitle: M-Labs/HeavyX: Next-generation FPGA SoC toolkit - M-Labs Git (at
tpbTitle: M-Labs/HeavyX: Next-generation FPGA SoC toolkit - eda/vivado.nix at master - M-Labs Git (at
hackerfoomithro: I hadn't seen that, thanks.03:07
hackerfooI was using this for Vivado. They also have a .nix for MiGen:
tpbTitle: GitHub - lukaslaobeyer/nix-fpgapkgs: Nix channel with FPGA development tools (at
mithrohackerfoo: He is the guy who did the really cool assembly assistant thingy ->
tpbTitle: GitHub - lukaslaobeyer/assemblyassist: Assistance for manually placing large numbers of components on a circuit board, as efficiently as possible. (at
*** _whitelogger has quit IRC05:25
*** _whitelogger has joined #symbiflow05:28
*** OmniMancer has joined #symbiflow07:00
*** proteusguy has joined #symbiflow08:28
*** celadon has quit IRC09:16
*** celadon has joined #symbiflow09:17
*** rvalles has joined #symbiflow10:06
*** citypw has quit IRC10:40
*** Vonter has quit IRC11:09
*** Vonter has joined #symbiflow11:37
*** duck2 has quit IRC12:00
*** Bertl_zZ is now known as Bertl12:09
*** Vonter has quit IRC12:37
*** Vonter has joined #symbiflow12:38
*** proteusguy has quit IRC12:43
sf-slack2<acomodi> litghost: v2x PR should be all right. The xc7 CI failed because of an issue in fasm2bels which is solved by
tpbTitle: fasm2bels: hotfix after changes by acomodi · Pull Request #605 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** proteusguy has joined #symbiflow13:12
sf-slack2<acomodi> litghost: I have also corrected and added documentation on PR, I will continue working on that. First thing is to solve genfasm issue when creating FASM lines of equivalent tiles.13:22
*** proteusguy has quit IRC13:29
*** OmniMancer has quit IRC13:30
*** proteusguy has joined #symbiflow13:42
sf-slack2<acomodi> I have a question about the conda environment: I do not why but the file is downloaded multiple times when building targets in symbiflow arch-defs. What could be the issue with that? Here there is a pastebin of the issue
tpbTitle: [100%] Generating env/ --2019-04-17 15:39:51-- - (at
litghostCheck the modified timestamp.  Make sure it is when the file was downloaded14:27
litghostI wonder if wget is writing some other time14:28
sf-slack2<acomodi> well, weirdly it says that Miniconda*.sh was downloaded on the 2nd of January 201914:31
*** citypw has joined #symbiflow14:33
sf-slack2<mkurc> @litghost I modified prjxray import scripts so that now all pips (including pseudo and bidirectional) are imported to the channels.db. I made a PR:
tpbTitle: Import of all pips (bidirectional and pseudo) to channels.db by mkurc-ant · Pull Request #604 · SymbiFlow/symbiflow-arch-defs · GitHub (at
sf-slack2<acomodi> litghost: this is Miniconda*.sh file stat
tpbTitle: stat File: Miniconda3-4.5.12-Linux-x86_64. - (at
sf-slack2<mkurc> @litghost BTW the arch defs CI is failing even on master. We need to merge
tpbTitle: fasm2bels: hotfix after changes by acomodi · Pull Request #605 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostWas waiting for green14:42
sf-slack2<kgugala> @litghost @mithro do you have any preference how sdfs should land in the DB folder?14:44
litghostWe talked about starting to add subdirectories14:45
sf-slack2<kgugala> additional timings folder with all the sdfs inside should do the job14:45
litghostProbably a good time to start14:45
sf-slack2<kgugala> cool, so let it be a subdir14:46
*** Bertl is now known as Bertl_oO14:53
*** Vonter_ has joined #symbiflow15:02
sf-slack2<acomodi> I think the issue with genfasm and equivalent tile types is a little bit harder than I first thought. The problem is that genfasm walks the `pbs` to get the `metadata`. Unfortunately, a `SLICEM` has different `modes` and `metas` (AFAIK) making my idea of a solution unfeasible.15:02
*** Vonter has quit IRC15:02
sf-slack2<acomodi> In fact, I was thinking to retrieve the correct `metadata` of the `equivalent tile` by traversing the pb_graph structure from the top tile down to the primitive, but the issue is: how can I traverse the graph and get the correct `meta` if, for instance, a SLICEM has different `modes` and children `pb_types` w.r.t. SLICEL?15:05
*** duck2 has joined #symbiflow15:06
sf-slack2<acomodi> If this issue makes sense and is real (maybe I am missing something), do you have an idea on how to proceed?15:06
sf-slack2<mkurc> On my side: I am currently progressing with the CLB split. I added new tile types to the SQL database. I also wrote code that inserts those new types to the VPR grid instead of CLBs. Tomorrow I will start with pips and pins relocation.15:10
litghostEquivalent tiles should have equivalent fasm15:34
litghostThe prefix will move to the tile once the split is complete15:34
sf-slack2<acomodi> Ok, so I guess this is not such a huge issue as I thought after all15:48
*** citypw has quit IRC15:50
sf-slack2<acomodi> litghost: I also got the results of the titan benchmarks for the `mode_selection` feature. Here's vaughnbetz comment on the comparison results:
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
sf-slack2<acomodi> litghost, mithro: I think I need some suggestions to compose a high level comment to the mode selection feature. One of the things that is not fully clear to me is why was this feature needed in the first place.16:10
litghostacomodi: It handles bugs in mode selection in the packer16:11
litghostacomodi: So my contribution is specifically about the idea that all edges have to come from the same mode16:11
litghostacomodi: This applies in two cases16:11
litghostacomodi: When VPR is picking route through wires is 116:11
litghostacomodi: So this line shows the route through fix:
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostacomodi: I added this bit:
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
litghostacomodi: Which is detecting invalid packing as a result of conflicting modes16:14
litghostacomodi: The general theme of the PR is handling edge cases where it is possible to construct mode trees that the packer could select invalid combinations16:15
litghostacomodi: In our case like packing a LUT, there is a top level DRAM vs LUT mode16:16
litghostacomodi: If the packer chooses the LUT mode for the LUT and DRAM mode for the DRAM, the cluster is invalid16:16
litghostacomodi: The previous could would ASSERT in that case16:16
litghostacomodi: The new code reports a cluster conflict, and either trys the next mode (which may work) or eventually starts a new cluster16:17
sf-slack2<acomodi> litghost: Ok, so, just to be sure, in the previous code the LUT mode for LUT and DRAM for DRAM it ended up in an assertion error, which now is correctly handled. Is this correct?16:20
sf-slack2<acomodi> litghost: Anyway, thanks, I will pack all this information in a high level comment and update the PR description16:20
litghostacomodi: Ya16:21
*** _whitelogger_ has joined #symbiflow16:32
*** _whitelogger has quit IRC16:34
sf-slack2<acomodi> litghost, mithro: I have updated the high level comment, please double-check if it is correct
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithroacomodi: I'm a bit concerned by the increase in pack time...16:56
sf-slack2<acomodi> mithro: I will double-check again the code (making it a triple-check I guess :)) and analyze which are the most time consuming steps. It seems odd also to me that the pack time increased by a non-negligible amount.16:59
sf-slack2<acomodi> anyway, I have solved with a workaround the genfasm issue for the equivalent tiles and tried `chain_packing_test` on HW. I have seen that all the carry chains have been placed in CLBLMs instead of CLBLLs and well, by testing on HW there are good and bad news.17:00
mithroacomodi: The packer should preference the most "populous" tile type first?17:01
sf-slack2<acomodi> good news is that nothing broke and something happened. Bad news is that only one carry chain out of 8 is blinking.17:01
sf-slack2<acomodi> mithro: Yeah, I actually "forced" the placer to use CLBLMs to check if everything still worked on HW.17:03
mithroacomodi: Ahh okay17:03
sf-slack2<acomodi> mithro: I am still dealing with the placer algorithm in order to let him choose the best configuration based both on "populousity" (I don't know if that is the correct word) and timing as well17:04
sf-slack2<acomodi> litghost: PR is now green on CI17:07
tpbTitle: Improve the Verilog to XML conversion process by acomodi · Pull Request #316 · SymbiFlow/symbiflow-arch-defs · GitHub (at
litghostacomodi: Thanks, still some outstanding review ocmments17:09
*** Maya-sama has joined #symbiflow18:28
*** Miyu has quit IRC18:28
*** Maya-sama is now known as Miyu18:32
sf-slack2<mkurc> @litghost I have a question regarding the CLB split: Are we aiming at having a top-level SLICE tile with a single SLICE site inside? Or at having a top-level SLICE tile with all content of the former SLICE site ?21:35
litghostmkurc: SLICEL tile contains SLICEL site21:36
litghostmkurc: Today the CLBLL_L contains two SLICEL sites, right21:36
sf-slack2<mkurc> @litghost Ok, thanks21:36
*** tux3 has quit IRC21:37
*** tux3 has joined #symbiflow21:37
*** Vonter_ has quit IRC22:39
*** Vonter has joined #symbiflow22:41

Generated by 2.13.1 by Marius Gedminas - find it at!