Thursday, 2019-04-04

*** tpb has joined #symbiflow00:00
mithroduck2: Sorry ran away to a meeting00:02
*** Risto has joined #symbiflow00:11
*** Risto has quit IRC00:13
hackerfooI plan on visiting the TC6 office tomorrow, for anyone that's around.00:13
*** futarisIRCcloud has joined #symbiflow00:23
*** david___ has joined #symbiflow00:29
*** hzeller has quit IRC00:31
*** david___ has quit IRC00:35
*** hzeller has joined #symbiflow00:58
sf-slack<risto.pejasinovic> Hello! I am undergrad student from Serbia studying Embedded Systems. I just found a post on r/FPGA about SymbiFlow. As I am very interested in open source tools for Digital Design, I am involved in one open-source project on this topic (PyGears). However I am new to Google Summer of Code. I would appreciate if someone is willing to answer some of my questions. Thanks.01:15
*** hzeller has quit IRC01:37
mithroristo.pejasinovic: Did you see our page which covers a lot of common questions?
tpbTitle: SymbiFlow - the GCC of FPGAs (at
sf-slack<mgielda> Hi Risto! Happy to see you here01:39
mithroacomodi / mkurc / litghost:
tpbTitle: Packer enhancements by MohamedEldafrawy · Pull Request #529 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
mithroThose changes to the packer allow having architectures with more than one chain per cluster. This is similar to the carry chains in the architecture shown in this figure where half of the ALMs share a carry chain together and the other half share another carry chain together.02:52
*** dmchristiansen has joined #symbiflow02:59
*** citypw has joined #symbiflow03:28
*** hzeller has joined #symbiflow03:58
*** zeigren[m] has joined #symbiflow04:10
*** lks has joined #symbiflow04:13
*** lks has quit IRC04:17
sf-slack<dwlsalmeida> Hello, first year EE student coming from Reddit.   You can check what I have been working at https:  Looking for a C++ or Python project for GSOC1904:19
*** dmchristiansen has quit IRC05:13
*** wingman2 has quit IRC05:17
*** wingman2 has joined #symbiflow05:22
*** which has joined #symbiflow05:34
*** which has quit IRC05:36
hackerfooI got up and running on NixOS. It was rough, but now I have something that works reliably and is portable (in two ways.)05:46
hackerfooI'd like to make official packages eventually.05:46
*** kraiskil has joined #symbiflow06:19
*** Bertl_zZ is now known as Bertl06:34
*** Bertl is now known as Bertl_oO07:07
*** proteusguy has joined #symbiflow07:37
*** hzeller has quit IRC07:39
*** kraiskil has quit IRC07:54
*** kraiskil has joined #symbiflow08:09
*** kraiskil has quit IRC08:30
*** risto has joined #symbiflow09:05
*** risto has quit IRC09:05
*** kraiskil has joined #symbiflow09:26
*** OmniMancer has joined #symbiflow09:31
sf-slack<acomodi> litghost: yes, if you could help me writing those comments as suggested in would be great09:38
tpbTitle: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at
*** kraiskil has quit IRC09:39
*** citypw has quit IRC10:08
sf-slack<acomodi> mithro: regarding #529 PR, as far as I understood it will also allow to have CC longer than the column length and correctly split, place and route very long CC10:25
sf-slack<mkurc> @acomodi I am not sure of that as splitting a CC would require passing through the fabric.10:32
*** dllb00 has joined #symbiflow10:37
sf-slack<mkurc> I made a drawing which illustrates the flow of prjxray database to the VPR import:
tpbTitle: Google Drawings - create diagrams and charts, for free. (at
*** proteusguy has quit IRC11:13
sf-slack<risto.pejasinovic> Thanks all! I have read FAQ and watched lectures it answered most of my questions. Unfortunately looks like I am a bit late to research project thoroughly, since it is massive.  I am mostly familiar with Xilinx FPGAs, precisely Zynq, but I worked with Kintex and Ultrascale also. I have knowledge of Xilinx primitives used in these FPGAs. I was thinking helping with support for Zynq arch descriptions, since I12:31
sf-slackown Zynq z7020 MYIR Z-Turn board, but it might be a bit ambitious since I am not so familiar with the project and there is little time for proposal.  I should note that for programming I mostly use Python, C, C++. For HDL I use SystemVerilog, but Verilog is not a problem for me.  Looking at the issue tracker on your github I cannot decide which one would be suitable for my skills, since I am not familiar with the project. Issue12:31
sf-slack#25 might be interesting since I have experience in Hardware debugging and testing. I am open for your advices on issues I might be able to take.  I can propose one idea of mine, but I am not sure if it is good for GSoC. I am working on Viola Jones Object Detection Hardware implementation. I've done SystemVerilog and PyGears (python framework for HW design ) implementation. Currently it is12:31
sf-slacktested on Zynq7020, maybe I could port it to Ice40 and use your synthesis tools to test them and find potential bugs. Also get familiar with your tools. This would be interesting for me since I would be able to test our HDL generated with PyGears with your tools. Since our goal is to provide completely open source flow for HW design.  Sorry for lengthy post. Best regards.12:31
tpbTitle: GitHub - bogdanvuk/pygears: HW Design: A Functional Approach (at
tpbTitle: GitHub - Risto97/cascade_classifier: Python, C, RTL implementation of Viola Jones cascade classifier, using pretrained model from opencv. (at
*** futarisIRCcloud has quit IRC12:32
*** hzeller has joined #symbiflow13:06
*** idioticgenius has joined #symbiflow13:28
*** idioticgenius has quit IRC13:28
*** abhidan has joined #symbiflow13:30
*** abhidan has quit IRC13:33
*** kraiskil has joined #symbiflow13:34
*** OmniMancer has quit IRC13:43
*** kraiskil has quit IRC13:47
*** kraiskil has joined #symbiflow13:49
*** kraiskil has quit IRC14:08
*** kraiskil has joined #symbiflow14:20
sf-slack<mkurc> Status update: Working towards an universal grid location mapping. In order to do this I am modifying ``, `` and `` so they will no longer depend on the prjxray database. All the information those scripts require is already imported to the `channels.db` database.14:23
litghostristo.pejasinovic: Porting prjxray to the Zynq z7020 (we have support for the z7010) and adding a fuzzer for the PS7 block would likely be a good project14:41
litghostristo.pejasinovic: We know there is something wrong with the 005 fuzzer on z7020 parts (
tpbTitle: 005-tilegrid fails for Zynq 7020 · Issue #697 · SymbiFlow/prjxray · GitHub (at
litghostacomodi: I can help with comments around the routing check.  mithro wrote some of the original stuff.  I believe mithro has some notes when the work was started, and I can fill in some of the additional work14:43
sf-slack<kgugala> @litghost @risto.pejasinovic actually we need to figure out which PS7 pin goes to which interconnect in the FPGA fabric. Having that Yosys can be updated to handle the PS7 instantiating. This indeed could be a nice task for GSoC14:43
litghostkgugala: I don't believe we have a PS7 fuzzer right now either?  So we need both the pin mapping and the fuzzer bits?14:44
sf-slack<kgugala> we don't need ps7 fuzzer. PS7 is always there - it's a matter of interconnect14:45
sf-slack<kgugala> We have base addresses14:45
sf-slack<kgugala> but we don't know which PS7 pin is connected to which interconnect14:46
litghostkgugala: It has bipips, which means that there are likely bits to control direction.14:46
sf-slack<kgugala> @acomodi worked on a PS7 some time ago14:46
sf-slack<kgugala> probably he can tell more14:49
*** kraiskil has quit IRC14:51
*** citypw has joined #symbiflow14:51
sf-slack<acomodi> litghost, @kgugala: while working on PS7, I have noticed that all the PS7 pins were headed to the very first left INT tiles column of the fabric. What I did was to create a fuzzer which only got the various INT tiles base addresses.14:56
sf-slack<acomodi> litghost: all the PS7 pins that are directed to the FPGA fabric do not seem to have a configurable direction14:57
sf-slack<acomodi> litghost: moreover, each single PS7 pin is fixed to a specific pip of a specific INT tile14:58
litghostacomodi: Okay14:58
sf-slack<acomodi> my last statement though is not verified (I have manually checked many of them, but I am not 100% sure all of them have this property)14:59
litghostacomodi: Cool15:00
sf-slack<acomodi> To be more clear though, the path from one PS7 pin to an INT tile is as follows: `PSS2_X13Y53/PSS2.PS7_MAXIGP1AWADDR14 --> INT_L_X0Y55/LOGIC_OUTS_L2`15:05
sf-slack<acomodi> where `PS7_MAXIGP1AWADDR14` is an axi related signal15:05
sf-slack<kgugala> hmm so ti is easy to get which pin goes where15:06
sf-slack<kgugala> those are encoded in the pip names15:06
litghostkgugala/acomodi: Shouldn't the PS7 pinmap be available in the pip list for the PS7 tile?15:06
litghostkguala: Exactly15:06
litghostThere is still work to make that usable, I don't think it is exploritory, so much as functional15:07
sf-slack<kgugala> we need to teach yosys about that15:07
sf-slack<kgugala> + add those to arch defs and routing graphs in vpr15:08
*** proteusguy has joined #symbiflow15:09
*** kraiskil has joined #symbiflow15:17
mithroWho wrote ?15:33
tpbTitle: DRAM configuration Project X-Ray 0.0-2066-gd562d7e documentation (at
*** hzeller has quit IRC15:33
litghostmithro: Me15:37
* litghost
*** hzeller has joined #symbiflow15:40
*** kraiskil has quit IRC15:42
*** kraiskil has joined #symbiflow15:48
*** kraiskil has quit IRC15:56
sf-slack<acomodi> equivalent tiles update: I have been going on with modifying the current data structure holding the ex top level pb_types (which now are identified in the XML arch definition as `tiles`). I have added an additional regression test and a new test architecture, which contains both SLICEM and SLICEL so to easily check the correct behavior of the equivalence tiles implementation.16:00
sf-slack<acomodi> I have also thought that it was better to specify in the `tile` which are the possible additional tiles that the first one could be placed into (e.g. SLICEL tile now has a new `equivalent_tile` mode which is SLICEM, in which it can be placed.16:03
*** kraiskil has joined #symbiflow16:14
litghostacomodi: Why make the "equivalent_tile" explicit, should that be computable?16:23
litghostacomodi: Or is the idea you only specific tile -> other tile, rather than vise versa?16:23
mithrolitghost: You forgot to include it in the ToC so it wasn't getting published :-)16:32
sf-slack<acomodi> litghost: exactly the idea is just to explicitly specify, for example, in the <tile name"slicem"> tag which other tile(s) can be used instead of that one during placement. Probably, as you said, the equivalent tiles could be computed automatically, given the pins (e.g. slicel has got a subset of slicem io pins, therefore a slicem can be added as an equivalent tile for the slicel, tell me if it makes sense)16:34
litghostacomodi: So I meant computed if specified, not fully automatic16:34
litghostacomodi: Can you write your new design in your document?16:34
*** Sumanth has joined #symbiflow16:35
sf-slack<acomodi> litghost: all right, I have already changed the example, but I need to add a more detailed description of it.16:36
*** kraiskil has quit IRC16:39
sf-slack<mgielda> @risto.pejasinovic do you think these kind of things could work for you as a topic? ideally you can help with something that's not strictly on the critical path but still helps the team move forward16:40
*** hzeller has quit IRC16:43
*** Sumanth has quit IRC16:44
mithrolitghost: I think we want to be explicit about what tiles are equivalent?16:50
litghostmithro: Yep.  I was talking about if I have A therefore B being computable from B can support A16:50
litghostmithro: Basically the reverse map16:51
litghostmithro: It's unclear from acomodi's description what the current plan is, so I'm going to wait for an updated design16:51
*** zkms has joined #symbiflow16:54
*** sumanth has joined #symbiflow16:59
sumanthHi! so I just got to know about the symbiflow project being selected for GSoC via reddit!17:00
sumanthI have very little time left and could really use some help in selecting a project and submitting a proposal. My major skill-set includes Verilog programming, Timing Analysis and scripting using Python and C++17:01
sumanthI'va also previously implemented a deep neural network acclerator in Verilog targeted towards virtex-7 FPGAs and have also recieved lot's of praise on GitHub for the same17:03
sf-slack<mgielda> Sumanh, interesting17:06
sf-slack<mgielda> Can you link to the nn accelerator?17:06
tpbTitle: GitHub - sumanth-kalluri/cnn_hardware_acclerator_for_fpga: This is a fully parameterized verilog implementation of computation kernels for accleration of the Inference of Convolutional Neural Networks on FPGAs (at
sumanthso after doing the research I had like three weeks to code it up in verilog and verify my design using python scripts. I managed to finish the three major mathematical operations of a CNN within this time. I've documented it quite well too!17:08
sumanthMay I know how I can get an invite for the slack channel of Symbiflow?17:13
sf-slack<kgugala> on there is a link to invitation page17:13
sf-slack<kgugala> this link
*** citypw has quit IRC17:17
sf-slack<acomodi> @litghost: I have updated the doc with my latest thoughts17:19
*** hotoso has joined #symbiflow17:30
sf-slack<acomodi> @litghost:
tpbTitle: Google Docs - create and edit documents online, for free. (at
*** sumanth has quit IRC17:44
*** hzeller has joined #symbiflow18:11
*** kraiskil has joined #symbiflow18:12
*** hzeller has joined #symbiflow18:13
hzellerIs it expected that vpr sometimes take reeeeally long time ? Currently I am buliding symbiflow-arch-defs, and the last two hours, my workstation was busy in the Generating top_dram_n2/artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test/top.route step.18:15
litghostHave you set the env var VPR_NUM_WORKERS?18:15
hzellerVPR used is the one from conda (it invokes symbiflow-arch-defs/build/env/conda/bin/vpr ), so not sure if it is a debug version of sorts18:15
hzellerno, I have not set VPR_NUM_WORKERS so far litghost as I wanted to start out with the default build18:16
litghostVPR_NUM_WORKERS is recommended if you have enough memory and CPU's, but I haven't measured the exact affect18:17
hzellercool. Yeah, I have 12 Xeon cores at my disposal, sounds like this is a good variable to set :)18:18
litghostIf the problem persists, run the route command manually and check the router output, there has been a couple cases where the router hit some kind of instability and failed to converge18:21
litghostBut I believe that shouldn't be happening at HEAD18:22
*** kraiskil has quit IRC18:26
hzellerThanks. I just interrupted, set the environment variable and ran make again. It now found murax_basys/artix7-xc7a50t-basys3-roi-virt-xc7a50t-basys3-test/toplevel.route as the first target to work on, time will tell how long it takes (it does only use 100% CPU though, so does not seem to use the parallelization opportunity). If it takes a long while again, I'll manually look into it.18:27
hzellerAnyway, next step for me would be to compile vpr locally and use that binary instead of the conda binary of unknown compile settings.18:28
sf-slack<acomodi> Run `make env` in the root directory of symbiflow and than run `make` again to build your desired target18:29
sf-slack<acomodi> CMake will process the environmental variable and make it effective18:30
*** sumanth has joined #symbiflow18:41
hzellermmh, so VPR_NUM_WORKERS seems to be an environment variable read by the vpr binary itself (around vpr_api.cpp:183, when flag is not set). Cmake does not seem to care or set the --num_workers flag on vpr calls if that environment variable was set at cmake time. Anyway, I have now invoked the command line directly with --num_workers to be sure :)18:46
mithrovpr: Add --balance_block_type_utilization option18:52
tpbTitle: vpr: Add --balance_block_type_utilization option · verilog-to-routing/[email protected] · GitHub (at
mithrokgugala / acomodi: That is similar to your round-robin packing, right?18:53
sf-slack<kgugala> round robin packing we added works in prepacker18:58
sf-slack<kgugala> it distributes atoms into molecules with pack_patterns18:59
sf-slack<kgugala> it tries to use pack patterns evenly18:59
sf-slack<kgugala> this is a work around for issues caused by introducing specialized carry chains19:00
sf-slack<kgugala> @mithro ^^19:00
sf-slack<kgugala> once we get rid of specialized CC's we should remove round robin prepacking19:01
mithrokgugala: That above commit adds an option for "If enabled, when a primitive can potentially be mapped to multiple block types the packer will pick the block type which (currently) has lower utilization."19:01
sf-slack<acomodi> mithro: by looking at it actually the option is enabled by default. I think the previous behavior was exactly the same. With this new commit there is the possibility to disable the balancing19:03
*** sumanth has quit IRC19:04
sf-slack<kgugala> @mithro but this one works in packer - it will not change pack_pattern, which was used to create molecule.19:04
sf-slack<kgugala> in our case the problem was that all the CC's were packed using one pack_pattern (e.g. CLBLL_L/SLICE0/CARRY)19:05
sf-slack<kgugala> so in the end we were using only 1/8 of available CC's19:06
*** sumanth has joined #symbiflow19:12
*** sumanth has quit IRC19:23
*** i8hantanu has joined #symbiflow19:31
*** kraiskil has joined #symbiflow20:17
sf-slack<xtjacob> Howdy. I saw the post on reddit about GSoC and I was interested in learning more about it20:32
mithroxtjacob: Did you see our GSoC page at ?20:32
tpbTitle: SymbiFlow - the GCC of FPGAs (at
sf-slack<xtjacob> I didn't, just saw the post on reddit. I'll take a look at it20:33
mithroThe docs for prjxray are looking a bit better now ->
tpbTitle: Welcome to Project X-Ray Project X-Ray 0.0-2078-gc7c8f00 documentation (at
mithroA lot of fuzzers are missing README files however...20:37
sf-slack<xtjacob> I see some things I'm interested in on the issue tracker on github. However, I'm already working full time during the summer so I'm not sure I can do GSoC. I'm interested in helping out though. Looks like a super cool project20:37
elmshackerfoo: You may be interested to look at this PR and
tpbTitle: WIP: Initial version of generic test fixture. by litghost · Pull Request #529 · SymbiFlow/symbiflow-arch-defs · GitHub (at
*** kraiskil has quit IRC21:22
tpbTitle: Makefiles for Xilinx Tools - Victor Yurkovsky (at
mithrohackerfoo: Hrm that is Xilinx ISE not vivado21:54
mithrohackerfoo: Maybe
tpbTitle: GitHub - cambridgehackers/fpgamake: Generates Makefiles to synthesize, place, and route verilog using Vivado (at
mithrohackerfoo: or
tpbTitle: GitHub - prashal/vivado_makefile_template: Xilinx Vivado Empty Makefile Project template (at
mithrohackerfoo: or
tpbTitle: GitHub - OpenPixelSystems/makefile-vivado-project: Generic Makefile project for a Vivado build (at
mithrohackerfoo: This is actually probably want you want ->
tpbTitle: yosys/examples/basys3 at master · YosysHQ/yosys · GitHub (at
mithrohackerfoo: Diagram done! ->
tpbTitle: Data Flow in SymbiFlow Arch Defs for Xilinx Series 7 Testing + Verification - Google Drawings (at
*** i8hantanu has quit IRC21:59
mithrohackerfoo: Doc to go with that diagram ->
tpbTitle: The ZipCPU by Gisselquist Technology (at
mithrohackerfoo: I could use some help auditing -- I'm trying to finish moving all the stuff from the prjxray wiki onto the readthedocs22:59
tpbTitle: WIP: Importing remaining wiki contents by mithro · Pull Request #757 · SymbiFlow/prjxray · GitHub (at
*** AndroUser has joined #symbiflow23:09
mithroelms: We should add a travis check for trailing white space23:15
*** futarisIRCcloud has joined #symbiflow23:15
elmsmithro: example?23:16
elmsof trailing whitespace I mean. I would think yapf would handle the python.23:17
mithroelms: In the docs...23:17
tpbTitle: Overview Sphinx 1.8.0 documentation (at
mithroduck2: How is your GSoC proposal going?23:27
*** AndroUser has quit IRC23:32
duck2mithro: i sent a draft proposal for the file formats project. however, my mind _was left_ in the nextpnr FASM idea. i'll be keeping an eye on it if time permits.23:34
mithroduck2: I've started adding some comments to your proposal now23:44
*** _whitelogger has quit IRC23:58

Generated by 2.13.1 by Marius Gedminas - find it at!