<hackerfoo>
I plan on visiting the TC6 office tomorrow, for anyone that's around.
futarisIRCcloud has joined #symbiflow
david___ has joined #symbiflow
hzeller has quit [Ping timeout: 264 seconds]
david___ has quit [Quit: Page closed]
hzeller has joined #symbiflow
<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.
<mithro>
Those 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.
dmchristiansen has joined #symbiflow
citypw has joined #symbiflow
hzeller has joined #symbiflow
zeigren[m] has joined #symbiflow
lks has joined #symbiflow
lks has quit [Client Quit]
<sf-slack>
<dwlsalmeida> Hello, first year EE student coming from Reddit. You can check what I have been working at https: github.com/dwlsalmeida Looking for a C++ or Python project for GSOC19
dmchristiansen has quit [Quit: Leaving]
wingman2 has quit [Ping timeout: 244 seconds]
wingman2 has joined #symbiflow
which has joined #symbiflow
which has quit [Client Quit]
<hackerfoo>
I got up and running on NixOS. It was rough, but now I have something that works reliably and is portable (in two ways.)
<hackerfoo>
I'd like to make official packages eventually.
<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 CC
<sf-slack>
<mkurc> @acomodi I am not sure of that as splitting a CC would require passing through the fabric.
<tpb>
Title: Google Drawings - create diagrams and charts, for free. (at docs.google.com)
proteusguy has quit [Remote host closed the connection]
<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 I
<sf-slack>
own 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. Issue
<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 https://github.com/bogdanvuk/pygears ) implementation. Currently it is
<sf-slack>
tested 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. https://github.com/Risto97/cascade_classifier 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.
<tpb>
Title: GitHub - Risto97/cascade_classifier: Python, C, RTL implementation of Viola Jones cascade classifier, using pretrained model from opencv. (at github.com)
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
hzeller has joined #symbiflow
idioticgenius has joined #symbiflow
idioticgenius has quit [Client Quit]
abhidan has joined #symbiflow
abhidan has quit [Client Quit]
kraiskil has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
kraiskil has quit [Ping timeout: 250 seconds]
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 244 seconds]
kraiskil has joined #symbiflow
<sf-slack>
<mkurc> Status update: Working towards an universal grid location mapping. In order to do this I am modifying `prjxray_routing_import.py`, `prjxray_create_edges.py` and `prjxray_assign_tile_pin_direction.py` so they will no longer depend on the prjxray database. All the information those scripts require is already imported to the `channels.db` database.
<litghost>
risto.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 project
<litghost>
acomodi: 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 work
<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 GSoC
<litghost>
kgugala: I don't believe we have a PS7 fuzzer right now either? So we need both the pin mapping and the fuzzer bits?
<sf-slack>
<kgugala> we don't need ps7 fuzzer. PS7 is always there - it's a matter of interconnect
<sf-slack>
<kgugala> We have base addresses
<sf-slack>
<kgugala> but we don't know which PS7 pin is connected to which interconnect
<litghost>
kgugala: It has bipips, which means that there are likely bits to control direction.
<sf-slack>
<kgugala> @acomodi worked on a PS7 some time ago
<sf-slack>
<kgugala> probably he can tell more
kraiskil has quit [Ping timeout: 268 seconds]
citypw has joined #symbiflow
<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.
<sf-slack>
<acomodi> litghost: all the PS7 pins that are directed to the FPGA fabric do not seem to have a configurable direction
<sf-slack>
<acomodi> litghost: moreover, each single PS7 pin is fixed to a specific pip of a specific INT tile
<litghost>
acomodi: Okay
<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)
<litghost>
acomodi: Cool
<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`
<sf-slack>
<acomodi> where `PS7_MAXIGP1AWADDR14` is an axi related signal
<sf-slack>
<kgugala> hmm so ti is easy to get which pin goes where
<sf-slack>
<kgugala> those are encoded in the pip names
<litghost>
kgugala/acomodi: Shouldn't the PS7 pinmap be available in the pip list for the PS7 tile?
<litghost>
kguala: Exactly
<litghost>
There is still work to make that usable, I don't think it is exploritory, so much as functional
<sf-slack>
<kgugala> we need to teach yosys about that
<sf-slack>
<kgugala> + add those to arch defs and routing graphs in vpr
<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.
<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.
kraiskil has joined #symbiflow
<litghost>
acomodi: Why make the "equivalent_tile" explicit, should that be computable?
<litghost>
acomodi: Or is the idea you only specific tile -> other tile, rather than vise versa?
<mithro>
litghost: You forgot to include it in the ToC so it wasn't getting published :-)
<litghost>
ah
<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)
<litghost>
acomodi: So I meant computed if specified, not fully automatic
<litghost>
acomodi: Can you write your new design in your document?
Sumanth has joined #symbiflow
<sf-slack>
<acomodi> litghost: all right, I have already changed the example, but I need to add a more detailed description of it.
kraiskil has quit [Ping timeout: 250 seconds]
<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 forward
hzeller has quit [Ping timeout: 268 seconds]
Sumanth has quit [Ping timeout: 256 seconds]
<mithro>
litghost: I think we want to be explicit about what tiles are equivalent?
<litghost>
mithro: Yep. I was talking about if I have A therefore B being computable from B can support A
<litghost>
mithro: Basically the reverse map
<litghost>
mithro: It's unclear from acomodi's description what the current plan is, so I'm going to wait for an updated design
zkms has joined #symbiflow
Sumanth has joined #symbiflow
<Sumanth>
Hi! so I just got to know about the symbiflow project being selected for GSoC via reddit!
<Sumanth>
I 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++
<Sumanth>
I'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 same
<sf-slack>
<mgielda> Sumanh, interesting
<sf-slack>
<mgielda> Can you link to the nn accelerator?
<tpb>
Title: 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 github.com)
<Sumanth>
so 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!
<Sumanth>
May I know how I can get an invite for the slack channel of Symbiflow?
<sf-slack>
<kgugala> on symbiflow.github.io there is a link to invitation page
<tpb>
Title: Google Docs - create and edit documents online, for free. (at docs.google.com)
Sumanth has quit [Ping timeout: 256 seconds]
hzeller has joined #symbiflow
hzeller has quit [Client Quit]
kraiskil has joined #symbiflow
hzeller has joined #symbiflow
<hzeller>
Is 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.
<litghost>
Have you set the env var VPR_NUM_WORKERS?
<hzeller>
VPR 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 sorts
<hzeller>
no, I have not set VPR_NUM_WORKERS so far litghost as I wanted to start out with the default build
<litghost>
VPR_NUM_WORKERS is recommended if you have enough memory and CPU's, but I haven't measured the exact affect
<hzeller>
cool. Yeah, I have 12 Xeon cores at my disposal, sounds like this is a good variable to set :)
<litghost>
If 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 converge
<litghost>
But I believe that shouldn't be happening at HEAD
kraiskil has quit [Ping timeout: 268 seconds]
<hzeller>
Thanks. 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.
<hzeller>
Anyway, next step for me would be to compile vpr locally and use that binary instead of the conda binary of unknown compile settings.
<sf-slack>
<acomodi> Run `make env` in the root directory of symbiflow and than run `make` again to build your desired target
<sf-slack>
<acomodi> CMake will process the environmental variable and make it effective
Sumanth has joined #symbiflow
<hzeller>
mmh, 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 :)
<mithro>
kgugala / acomodi: That is similar to your round-robin packing, right?
<sf-slack>
<kgugala> round robin packing we added works in prepacker
<sf-slack>
<kgugala> it distributes atoms into molecules with pack_patterns
<sf-slack>
<kgugala> it tries to use pack patterns evenly
<sf-slack>
<kgugala> this is a work around for issues caused by introducing specialized carry chains
<sf-slack>
<kgugala> @mithro ^^
<sf-slack>
<kgugala> once we get rid of specialized CC's we should remove round robin prepacking
<mithro>
kgugala: 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."
<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 balancing
Sumanth has quit [Ping timeout: 256 seconds]
<sf-slack>
<kgugala> @mithro but this one works in packer - it will not change pack_pattern, which was used to create molecule.
<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)
<sf-slack>
<kgugala> so in the end we were using only 1/8 of available CC's
Sumanth has joined #symbiflow
Sumanth has quit [Ping timeout: 256 seconds]
i8hantanu has joined #symbiflow
kraiskil has joined #symbiflow
<sf-slack>
<xtjacob> Howdy. I saw the post on reddit about GSoC and I was interested in learning more about it
<mithro>
A lot of fuzzers are missing README files however...
<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 project
<tpb>
Title: The ZipCPU by Gisselquist Technology (at zipcpu.com)
<mithro>
hackerfoo: I could use some help auditing https://github.com/SymbiFlow/prjxray/pull/757 -- I'm trying to finish moving all the stuff from the prjxray wiki onto the readthedocs
<tpb>
Title: WIP: Importing remaining wiki contents by mithro · Pull Request #757 · SymbiFlow/prjxray · GitHub (at github.com)
<hackerfoo>
Sure
AndroUser has joined #symbiflow
<mithro>
elms: We should add a travis check for trailing white space
futarisIRCcloud has joined #symbiflow
<elms>
mithro: example?
<elms>
of trailing whitespace I mean. I would think yapf would handle the python.
AndroUser has quit [Remote host closed the connection]
<duck2>
mithro: 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.
<mithro>
duck2: I've started adding some comments to your proposal now