| *** tpb has joined #symbiflow | 00:00 | |
| mithro | duck2: Sorry ran away to a meeting | 00:02 |
|---|---|---|
| *** Risto has joined #symbiflow | 00:11 | |
| *** Risto has quit IRC | 00:13 | |
| hackerfoo | I plan on visiting the TC6 office tomorrow, for anyone that's around. | 00:13 |
| *** futarisIRCcloud has joined #symbiflow | 00:23 | |
| *** david___ has joined #symbiflow | 00:29 | |
| *** hzeller has quit IRC | 00:31 | |
| *** david___ has quit IRC | 00:35 | |
| *** hzeller has joined #symbiflow | 00: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 IRC | 01:37 | |
| mithro | risto.pejasinovic: Did you see our page which covers a lot of common questions? https://symbiflow.github.io/summer-of-code | 01:39 |
| tpb | Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io) | 01:39 |
| sf-slack | <mgielda> Hi Risto! Happy to see you here | 01:39 |
| mithro | acomodi / mkurc / litghost: https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/529 | 02:52 |
| tpb | Title: Packer enhancements by MohamedEldafrawy · Pull Request #529 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 02:52 |
| 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. | 02:52 |
| *** dmchristiansen has joined #symbiflow | 02:59 | |
| *** citypw has joined #symbiflow | 03:28 | |
| *** hzeller has joined #symbiflow | 03:58 | |
| *** zeigren[m] has joined #symbiflow | 04:10 | |
| *** lks has joined #symbiflow | 04:13 | |
| *** lks has quit IRC | 04:17 | |
| 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 | 04:19 |
| *** dmchristiansen has quit IRC | 05:13 | |
| *** wingman2 has quit IRC | 05:17 | |
| *** wingman2 has joined #symbiflow | 05:22 | |
| *** which has joined #symbiflow | 05:34 | |
| *** which has quit IRC | 05:36 | |
| 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.) | 05:46 |
| hackerfoo | I'd like to make official packages eventually. | 05:46 |
| *** kraiskil has joined #symbiflow | 06:19 | |
| *** Bertl_zZ is now known as Bertl | 06:34 | |
| *** Bertl is now known as Bertl_oO | 07:07 | |
| *** proteusguy has joined #symbiflow | 07:37 | |
| *** hzeller has quit IRC | 07:39 | |
| *** kraiskil has quit IRC | 07:54 | |
| *** kraiskil has joined #symbiflow | 08:09 | |
| *** kraiskil has quit IRC | 08:30 | |
| *** risto has joined #symbiflow | 09:05 | |
| *** risto has quit IRC | 09:05 | |
| *** kraiskil has joined #symbiflow | 09:26 | |
| *** OmniMancer has joined #symbiflow | 09:31 | |
| sf-slack | <acomodi> litghost: yes, if you could help me writing those comments as suggested in https://github.com/verilog-to-routing/vtr-verilog-to-routing/pull/517#issuecomment-479609302 would be great | 09:38 |
| tpb | Title: Mode selection feature by acomodi · Pull Request #517 · verilog-to-routing/vtr-verilog-to-routing · GitHub (at github.com) | 09:39 |
| *** kraiskil has quit IRC | 09:39 | |
| *** citypw has quit IRC | 10: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 CC | 10: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 #symbiflow | 10:37 | |
| sf-slack | <mkurc> I made a drawing which illustrates the flow of prjxray database to the VPR import: https://docs.google.com/drawings/d/1VxgiArX2wfF3oWZiCoIedLdZvjTCBhyGdMDcTKnU-8w | 11:02 |
| tpb | Title: Google Drawings - create diagrams and charts, for free. (at docs.google.com) | 11:02 |
| *** proteusguy has quit IRC | 11: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 I | 12:31 |
| 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 | 12: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 https://github.com/bogdanvuk/pygears ) implementation. Currently it is | 12:31 |
| 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. | 12:31 |
| tpb | Title: GitHub - bogdanvuk/pygears: HW Design: A Functional Approach (at github.com) | 12:31 |
| tpb | Title: GitHub - Risto97/cascade_classifier: Python, C, RTL implementation of Viola Jones cascade classifier, using pretrained model from opencv. (at github.com) | 12:31 |
| *** futarisIRCcloud has quit IRC | 12:32 | |
| *** hzeller has joined #symbiflow | 13:06 | |
| *** idioticgenius has joined #symbiflow | 13:28 | |
| *** idioticgenius has quit IRC | 13:28 | |
| *** abhidan has joined #symbiflow | 13:30 | |
| *** abhidan has quit IRC | 13:33 | |
| *** kraiskil has joined #symbiflow | 13:34 | |
| *** OmniMancer has quit IRC | 13:43 | |
| *** kraiskil has quit IRC | 13:47 | |
| *** kraiskil has joined #symbiflow | 13:49 | |
| *** kraiskil has quit IRC | 14:08 | |
| *** kraiskil has joined #symbiflow | 14:20 | |
| 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. | 14:23 |
| 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 | 14:41 |
| litghost | risto.pejasinovic: We know there is something wrong with the 005 fuzzer on z7020 parts (https://github.com/SymbiFlow/prjxray/issues/697) | 14:42 |
| tpb | Title: 005-tilegrid fails for Zynq 7020 · Issue #697 · SymbiFlow/prjxray · GitHub (at github.com) | 14:42 |
| 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 | 14: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 GSoC | 14:43 |
| 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? | 14:44 |
| sf-slack | <kgugala> we don't need ps7 fuzzer. PS7 is always there - it's a matter of interconnect | 14:45 |
| sf-slack | <kgugala> We have base addresses | 14:45 |
| sf-slack | <kgugala> but we don't know which PS7 pin is connected to which interconnect | 14:46 |
| litghost | kgugala: 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 ago | 14:46 |
| sf-slack | <kgugala> probably he can tell more | 14:49 |
| *** kraiskil has quit IRC | 14:51 | |
| *** citypw has joined #symbiflow | 14: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 direction | 14:57 |
| sf-slack | <acomodi> litghost: moreover, each single PS7 pin is fixed to a specific pip of a specific INT tile | 14:58 |
| litghost | acomodi: Okay | 14: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 |
| litghost | acomodi: Cool | 15: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 signal | 15:05 |
| sf-slack | <kgugala> hmm so ti is easy to get which pin goes where | 15:06 |
| sf-slack | <kgugala> those are encoded in the pip names | 15:06 |
| litghost | kgugala/acomodi: Shouldn't the PS7 pinmap be available in the pip list for the PS7 tile? | 15:06 |
| litghost | kguala: Exactly | 15:06 |
| litghost | There is still work to make that usable, I don't think it is exploritory, so much as functional | 15:07 |
| sf-slack | <kgugala> we need to teach yosys about that | 15:07 |
| sf-slack | <kgugala> + add those to arch defs and routing graphs in vpr | 15:08 |
| *** proteusguy has joined #symbiflow | 15:09 | |
| *** kraiskil has joined #symbiflow | 15:17 | |
| mithro | Who wrote https://prjxray.readthedocs.io/en/latest/architecture/dram_configuration.html ? | 15:33 |
| tpb | Title: DRAM configuration Project X-Ray 0.0-2066-gd562d7e documentation (at prjxray.readthedocs.io) | 15:33 |
| *** hzeller has quit IRC | 15:33 | |
| litghost | mithro: Me | 15:37 |
| * litghost https://github.com/SymbiFlow/prjxray/commits/master/docs/architecture/dram_configuration.rst | 15:37 | |
| *** hzeller has joined #symbiflow | 15:40 | |
| *** kraiskil has quit IRC | 15:42 | |
| *** kraiskil has joined #symbiflow | 15:48 | |
| *** kraiskil has quit IRC | 15: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 #symbiflow | 16:14 | |
| litghost | acomodi: Why make the "equivalent_tile" explicit, should that be computable? | 16:23 |
| litghost | acomodi: Or is the idea you only specific tile -> other tile, rather than vise versa? | 16:23 |
| mithro | litghost: You forgot to include it in the ToC so it wasn't getting published :-) | 16:32 |
| litghost | ah | 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 |
| litghost | acomodi: So I meant computed if specified, not fully automatic | 16:34 |
| litghost | acomodi: Can you write your new design in your document? | 16:34 |
| *** Sumanth has joined #symbiflow | 16: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 IRC | 16: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 forward | 16:40 |
| *** hzeller has quit IRC | 16:43 | |
| *** Sumanth has quit IRC | 16:44 | |
| mithro | litghost: I think we want to be explicit about what tiles are equivalent? | 16:50 |
| litghost | mithro: Yep. I was talking about if I have A therefore B being computable from B can support A | 16:50 |
| litghost | mithro: Basically the reverse map | 16:51 |
| litghost | mithro: It's unclear from acomodi's description what the current plan is, so I'm going to wait for an updated design | 16:51 |
| *** zkms has joined #symbiflow | 16:54 | |
| *** sumanth has joined #symbiflow | 16:59 | |
| sumanth | Hi! so I just got to know about the symbiflow project being selected for GSoC via reddit! | 17:00 |
| 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++ | 17:01 |
| 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 | 17:03 |
| sf-slack | <mgielda> Sumanh, interesting | 17:06 |
| sf-slack | <mgielda> Can you link to the nn accelerator? | 17:06 |
| sumanth | sure https://github.com/sumanth-kalluri/cnn_hardware_acclerator_for_fpga | 17:07 |
| 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) | 17:07 |
| 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! | 17:08 |
| sumanth | May I know how I can get an invite for the slack channel of Symbiflow? | 17:13 |
| sf-slack | <kgugala> on symbiflow.github.io there is a link to invitation page | 17:13 |
| sf-slack | <kgugala> this link https://symbiflow.slack.com/join/shared_invite/enQtNTkyMjcyNTkzOTY4LWE4MTk2YTllMDAzZDAyYzI2Yzk2MzQ4YmViN2EyMDY2MGNiYWIzMGJhYTc2ODI4MTBhZTRmMDllZGFlY2U0MTc | 17:14 |
| *** citypw has quit IRC | 17:17 | |
| sf-slack | <acomodi> @litghost: I have updated the doc with my latest thoughts | 17:19 |
| *** hotoso has joined #symbiflow | 17:30 | |
| sf-slack | <acomodi> @litghost: https://docs.google.com/document/d/1lWLgZ5fCwKUgPh1MaOoAHwKBBr1ZAQLDzPkJtzTjLvQ/ | 17:31 |
| tpb | Title: Google Docs - create and edit documents online, for free. (at docs.google.com) | 17:31 |
| *** sumanth has quit IRC | 17:44 | |
| *** hzeller has joined #symbiflow | 18:11 | |
| *** kraiskil has joined #symbiflow | 18:12 | |
| *** hzeller has joined #symbiflow | 18:13 | |
| 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. | 18:15 |
| litghost | Have you set the env var VPR_NUM_WORKERS? | 18:15 |
| 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 | 18:15 |
| hzeller | no, I have not set VPR_NUM_WORKERS so far litghost as I wanted to start out with the default build | 18:16 |
| litghost | VPR_NUM_WORKERS is recommended if you have enough memory and CPU's, but I haven't measured the exact affect | 18:17 |
| hzeller | cool. Yeah, I have 12 Xeon cores at my disposal, sounds like this is a good variable to set :) | 18:18 |
| 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 | 18:21 |
| litghost | But I believe that shouldn't be happening at HEAD | 18:22 |
| *** kraiskil has quit IRC | 18:26 | |
| 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. | 18:27 |
| 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. | 18:28 |
| sf-slack | <acomodi> Run `make env` in the root directory of symbiflow and than run `make` again to build your desired target | 18:29 |
| sf-slack | <acomodi> CMake will process the environmental variable and make it effective | 18:30 |
| *** sumanth has joined #symbiflow | 18:41 | |
| 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 :) | 18:46 |
| mithro | vpr: Add --balance_block_type_utilization option | 18:52 |
| mithro | acomodi: https://github.com/verilog-to-routing/vtr-verilog-to-routing/commit/d4771a1e5cb4b9c2501abf9fb6768d9a7d5dc45e | 18:52 |
| tpb | Title: vpr: Add --balance_block_type_utilization option · verilog-to-routing/vtr-verilog-to-routing@d4771a1 · GitHub (at github.com) | 18:52 |
| mithro | kgugala / acomodi: That is similar to your round-robin packing, right? | 18:53 |
| sf-slack | <kgugala> round robin packing we added works in prepacker | 18:58 |
| sf-slack | <kgugala> it distributes atoms into molecules with pack_patterns | 18:59 |
| sf-slack | <kgugala> it tries to use pack patterns evenly | 18:59 |
| sf-slack | <kgugala> this is a work around for issues caused by introducing specialized carry chains | 19:00 |
| sf-slack | <kgugala> @mithro ^^ | 19:00 |
| sf-slack | <kgugala> once we get rid of specialized CC's we should remove round robin prepacking | 19:01 |
| 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." | 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 balancing | 19:03 |
| *** sumanth has quit IRC | 19: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's | 19:06 |
| *** sumanth has joined #symbiflow | 19:12 | |
| *** sumanth has quit IRC | 19:23 | |
| *** i8hantanu has joined #symbiflow | 19:31 | |
| *** kraiskil has joined #symbiflow | 20:17 | |
| sf-slack | <xtjacob> Howdy. I saw the post on reddit about GSoC and I was interested in learning more about it | 20:32 |
| mithro | xtjacob: Did you see our GSoC page at https://symbiflow.github.io/summer-of-code ? | 20:32 |
| tpb | Title: SymbiFlow - the GCC of FPGAs (at symbiflow.github.io) | 20:32 |
| sf-slack | <xtjacob> I didn't, just saw the post on reddit. I'll take a look at it | 20:33 |
| mithro | The docs for prjxray are looking a bit better now -> https://prjxray.readthedocs.io/en/latest/ | 20:33 |
| tpb | Title: Welcome to Project X-Ray Project X-Ray 0.0-2078-gc7c8f00 documentation (at prjxray.readthedocs.io) | 20:33 |
| mithro | A 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 project | 20:37 |
| elms | hackerfoo: You may be interested to look at this PR https://github.com/SymbiFlow/symbiflow-arch-defs/pull/529 and https://github.com/SymbiFlow/ideas/issues/25 | 20:53 |
| tpb | Title: WIP: Initial version of generic test fixture. by litghost · Pull Request #529 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 20:53 |
| *** kraiskil has quit IRC | 21:22 | |
| mithro | hackerfoo: https://www.fpgarelated.com/showarticle/786.php | 21:54 |
| tpb | Title: Makefiles for Xilinx Tools - Victor Yurkovsky (at www.fpgarelated.com) | 21:54 |
| mithro | hackerfoo: Hrm that is Xilinx ISE not vivado | 21:54 |
| mithro | hackerfoo: Maybe https://github.com/cambridgehackers/fpgamake | 21:54 |
| tpb | Title: GitHub - cambridgehackers/fpgamake: Generates Makefiles to synthesize, place, and route verilog using Vivado (at github.com) | 21:54 |
| mithro | hackerfoo: or https://github.com/prashal/vivado_makefile_template | 21:55 |
| tpb | Title: GitHub - prashal/vivado_makefile_template: Xilinx Vivado Empty Makefile Project template (at github.com) | 21:55 |
| mithro | hackerfoo: or https://github.com/OpenPixelSystems/makefile-vivado-project | 21:55 |
| tpb | Title: GitHub - OpenPixelSystems/makefile-vivado-project: Generic Makefile project for a Vivado build (at github.com) | 21:55 |
| mithro | hackerfoo: This is actually probably want you want -> https://github.com/YosysHQ/yosys/tree/master/examples/basys3 | 21:55 |
| tpb | Title: yosys/examples/basys3 at master · YosysHQ/yosys · GitHub (at github.com) | 21:56 |
| mithro | hackerfoo: Diagram done! -> https://docs.google.com/drawings/d/1-FmukrW4YtreRwkA4JKkYd-siscC3OvDTq8rKreOVHE/edit?usp=sharing | 21:58 |
| tpb | Title: Data Flow in SymbiFlow Arch Defs for Xilinx Series 7 Testing + Verification - Google Drawings (at docs.google.com) | 21:58 |
| *** i8hantanu has quit IRC | 21:59 | |
| mithro | hackerfoo: Doc to go with that diagram -> https://docs.google.com/document/d/11wJUvr2aVBkUiuYYsFN07jkoYr_ccWlLLLFH8YQw8uQ/edit?usp=sharing | 22:19 |
| mithro | hackerfoo: https://zipcpu.com/formal/formal.html | 22:44 |
| tpb | Title: The ZipCPU by Gisselquist Technology (at zipcpu.com) | 22:44 |
| 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 | 22:59 |
| tpb | Title: WIP: Importing remaining wiki contents by mithro · Pull Request #757 · SymbiFlow/prjxray · GitHub (at github.com) | 22:59 |
| hackerfoo | Sure | 23:00 |
| *** AndroUser has joined #symbiflow | 23:09 | |
| mithro | elms: We should add a travis check for trailing white space | 23:15 |
| *** futarisIRCcloud has joined #symbiflow | 23:15 | |
| elms | mithro: example? | 23:16 |
| elms | of trailing whitespace I mean. I would think yapf would handle the python. | 23:17 |
| mithro | elms: In the docs... | 23:17 |
| hackerfoo | http://www.sphinx-doc.org/en/stable/ | 23:19 |
| tpb | Title: Overview Sphinx 1.8.0 documentation (at www.sphinx-doc.org) | 23:19 |
| mithro | duck2: How is your GSoC proposal going? | 23:27 |
| *** AndroUser has quit IRC | 23:32 | |
| 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. | 23:34 |
| mithro | duck2: I've started adding some comments to your proposal now | 23:44 |
| *** _whitelogger has quit IRC | 23:58 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!