| *** tpb has joined #symbiflow | 00:00 | |
| *** _whitelogger has joined #symbiflow | 00:01 | |
| mithro | kgugala: I put a whole bunch of test files into https://github.com/SymbiFlow/python-sdf-timing/tree/master/tests/data for you to check with too... | 00:38 |
|---|---|---|
| tpb | Title: python-sdf-timing/tests/data at master · SymbiFlow/python-sdf-timing · GitHub (at github.com) | 00:38 |
| *** _whitelogger has quit IRC | 00:46 | |
| *** _whitelogger has joined #symbiflow | 00:49 | |
| duck2 | mithro: i'm going offline -- it's almost morning here. i'll follow some links and update&clarify the proposal tomorrow. what I'm thinking about is to drop the XML parser generator part, because i'm having trouble determining its exact scope(how much will I need to reinvent? there are many parser generators around but they are specialized...) and it | 01:11 |
| duck2 | kind of divides the project into two projects. | 01:11 |
| *** _whitelogger has quit IRC | 02:22 | |
| *** _whitelogger has joined #symbiflow | 02:25 | |
| zeigren[m] | Hey all I'm interested in helping out as part of the GSoC and am trying to figure out what I could help with. I was thinking I might be able to help in the Docker department or with package management, I'm all about making stuff easier to use. As far as Docker goes I think a fragmented approach would work best for SymbiFlow. Each tool has its own container (I think some do already) that can be easily maintained on their | 02:46 |
| zeigren[m] | own, easy to add new tools, easier to keep bloat down since you can pick and choose what you need, easily switch between dev and stable containers, etc... With Docker compose this is all fairly easy to do for the end user and should lend well to CI/CD. Thoughts? | 02:46 |
| mithro | zeigren[m]: I'm not sure that would be a high priority project at the moment | 03:15 |
| *** _whitelogger has quit IRC | 03:34 | |
| *** _whitelogger has joined #symbiflow | 03:37 | |
| hackerfoo | zeigren[m]: I'd like to get everything into Nixpkgs: https://github.com/NixOS/nixpkgs | 03:50 |
| tpb | Title: GitHub - NixOS/nixpkgs: Nix Packages collection (at github.com) | 03:50 |
| hackerfoo | That should cover all Linux distros and MacOS. | 03:51 |
| sf-slack | <saisumanthkalluri> Hi! Can someone please tell me what might be some good issues to solve based on Verilog that might be a good choice for my GSoC proposal? If not Verilog Python would be my next choice so I'd like to know important issues based on Python as well. I just discovered this very late and could use any help in making my project selection easier. Thank you! | 03:55 |
| *** citypw has joined #symbiflow | 04:00 | |
| zeigren[m] | mithro: That's fair, focusing on conda or Nixpkgs as hackerfoo mentioned might be better and in turn would make things like Docker containers easier down the line. But if that's not super pertinent right now python-sdf-timing looks interesting and I'm not opposed to the myriad of documentation related tasks in SymbiFlow/ideas | 04:21 |
| mithro | Improving sphinx by adding verilog support would be a good project | 04:23 |
| mithro | Testing on hardware would be interesting | 04:28 |
| mithro | A html+javascript graphical viewer for the databases and chipdb would be good too | 04:30 |
| *** _whitelogger has quit IRC | 04:43 | |
| *** _whitelogger has joined #symbiflow | 04:46 | |
| *** Bertl_oO is now known as bertl_zZ | 04:57 | |
| *** _whitelogger has quit IRC | 05:07 | |
| *** _whitelogger has joined #symbiflow | 05:10 | |
| zeigren[m] | Ooh I'm all about the hardware testing, wouldn't mind designing any hardware/adapter boards either. I imagine the idea is to not only verify that the design works in general but to also verify things like timing automatically? | 05:22 |
| *** OmniMancer has joined #symbiflow | 05:26 | |
| *** _whitelogger has quit IRC | 05:37 | |
| *** _whitelogger has joined #symbiflow | 05:40 | |
| sf-slack | <christiansen.daniel> Hi, I'm interested in writing a GSoC proposal and this issue caught my eye: https://github.com/SymbiFlow/ideas/issues/17 Since I'm a little late to this, I wanted to make sure that that would be a useful problem to focus on. Thank you. | 05:42 |
| tpb | Title: Create a really good library for parsing / producing SDF files · Issue #17 · SymbiFlow/ideas · GitHub (at github.com) | 05:42 |
| *** Sha has joined #symbiflow | 05:44 | |
| *** sf-slack has quit IRC | 06:04 | |
| *** sf-slack has joined #symbiflow | 06:04 | |
| *** _whitelogger has quit IRC | 06:25 | |
| *** _whitelogger has joined #symbiflow | 06:28 | |
| *** Sha has quit IRC | 06:33 | |
| *** mrhat2010[m] has quit IRC | 06:39 | |
| *** zeigren[m] has quit IRC | 06:39 | |
| *** xobs has quit IRC | 06:39 | |
| *** galv[m] has quit IRC | 06:39 | |
| *** galv[m] has joined #symbiflow | 06:50 | |
| *** zeigren[m] has joined #symbiflow | 07:21 | |
| *** xobs has joined #symbiflow | 07:21 | |
| *** mrhat2010[m] has joined #symbiflow | 07:21 | |
| *** OmniMancer has quit IRC | 07:37 | |
| *** kraiskil has joined #symbiflow | 07:37 | |
| *** lopsided98 has quit IRC | 08:11 | |
| *** lopsided98_ has joined #symbiflow | 08:11 | |
| sf-slack | <kgugala> Hi @christiansen.daniel those tools are already in progress | 08:15 |
| sf-slack | <kgugala> see https://github.com/SymbiFlow/python-sdf-timing | 08:15 |
| tpb | Title: GitHub - SymbiFlow/python-sdf-timing: Python library for working Standard Delay Format (SDF) Timing Annotation files. (at github.com) | 08:15 |
| sf-slack | <kgugala> SDF creator is a part of this PR https://github.com/SymbiFlow/prjxray/pull/706 | 08:16 |
| tpb | Title: WIP: fuzzers: timings: add bel timing fuzzer by kgugala · Pull Request #706 · SymbiFlow/prjxray · GitHub (at github.com) | 08:17 |
| sf-slack | <kgugala> this, however could be a standalone tool | 08:17 |
| sf-slack | <kgugala> right now it generates what was needed for the BEL timing fuzzer | 08:18 |
| sf-slack | <kgugala> and I didn't test it very extensively | 08:18 |
| sf-slack | <kgugala> so there are some issues to address here | 08:18 |
| *** kraiskil has quit IRC | 08:35 | |
| *** kraiskil has joined #symbiflow | 08:56 | |
| *** kraiskil has quit IRC | 09:01 | |
| *** citypw has quit IRC | 09:02 | |
| *** futarisIRCcloud has quit IRC | 09:04 | |
| *** kraiskil has joined #symbiflow | 09:14 | |
| *** i8hantanu has joined #symbiflow | 09:30 | |
| *** futarisIRCcloud has joined #symbiflow | 09:40 | |
| *** zeigren[m] has quit IRC | 10:01 | |
| *** mrhat2010[m] has quit IRC | 10:01 | |
| *** galv[m] has quit IRC | 10:01 | |
| *** xobs has quit IRC | 10:01 | |
| *** galv[m] has joined #symbiflow | 10:11 | |
| *** zeigren[m] has joined #symbiflow | 10:39 | |
| *** xobs has joined #symbiflow | 10:39 | |
| *** mrhat2010[m] has joined #symbiflow | 10:39 | |
| *** citypw has joined #symbiflow | 11:09 | |
| *** ipieter has joined #symbiflow | 11:36 | |
| *** bertl_zZ is now known as Bertl | 12:22 | |
| *** ipieter has quit IRC | 12:35 | |
| *** kraiskil has quit IRC | 13:05 | |
| *** kraiskil has joined #symbiflow | 13:22 | |
| *** futarisIRCcloud has quit IRC | 13:59 | |
| *** i8hantanu has quit IRC | 14:00 | |
| sf-slack | <mkurc> I created a generic mechanism for tile location mapping. This is still a WIP though: https://github.com/SymbiFlow/symbiflow-arch-defs/pull/537 | 14:12 |
| tpb | Title: WIP: Tile grid location mapping by mkurc-ant · Pull Request #537 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com) | 14:12 |
| *** kraiskil has quit IRC | 14:26 | |
| *** Bertl is now known as Bertl_oO | 14:58 | |
| sf-slack | <mgielda> https://github.com/SymbiFlow/symbiflow-docs/issues/3 | 15:13 |
| tpb | Title: integrate other documentations into this top-level documentation · Issue #3 · SymbiFlow/symbiflow-docs · GitHub (at github.com) | 15:13 |
| sf-slack | <mgielda> @me1 plz comment | 15:13 |
| *** kraiskil has joined #symbiflow | 15:28 | |
| sf-slack | <risto.pejasinovic> Sorry for not responding, was busy yesterday. Thank you for recommendations. @litghost @kgugala Porting prjxraj to Zynq z7020 sounds interesting to me. I could probably reuse alot from z7010 support. I am not following you yet on terms you are using (fuzzers etc..) I need to do research, hopefully this is good start? https://prjxray.readthedocs.io/en/latest/ @mgielda Yes I think I will pick topic from | 15:42 |
| sf-slack | above. Yes I would like to start on something small for GSoC, I will probably continue to contribute after GSoC because I am trying to avoid Vivado as much as possible. I read somewhere that you recommend students to open their proposals so others can see. Dont know where to find them if someone opened it. It would save me some time on formatting etc... since I am on tight schedule now. | 15:42 |
| tpb | Title: Welcome to Project X-Ray Project X-Ray 0.0-2083-g78c47ab documentation (at prjxray.readthedocs.io) | 15:42 |
| sf-slack | <kgugala> @risto.pejasinovic yes, reading that is a good start, just keep in mind that this is a very dynamic project so some parts of the doc may not be completely up to date | 15:44 |
| sf-slack | <kgugala> but at least glossary should be ;) | 15:44 |
| sf-slack | <risto.pejasinovic> @kgugala Thanks, noted. | 15:56 |
| *** flow has joined #symbiflow | 15:59 | |
| flow | Hey, thanks for the awesome work! I screwed up and assumed that project Trellis would support all ECP5 devices and did not realize that there was no support for the small LFE5U-12 devices. I allready made a PCB design and got it fabricated... Are there any plans to include LFE5U-12 support? | 16:04 |
| sorear | What do you mean? | 16:06 |
| daveshah | There is already ECP5 support, it's just not very public for reasons | 16:07 |
| flow | I just setup the nextpnr toolchain and it only showed support for the LFE5-25, LFE5-45 and LFE5-85 | 16:07 |
| daveshah | Yes, those are the three ECP5 die variants | 16:07 |
| flow | https://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/LFE5U-12F-7BG256C/LFE5U-12F-7BG256C-ND/9553930 | 16:08 |
| tpb | Title: LFE5U-12F-7BG256C Lattice Semiconductor Corporation | Integrated Circuits (ICs) | DigiKey (at www.digikey.com) | 16:08 |
| daveshah | https://github.com/SymbiFlow/prjtrellis/issues/55 | 16:08 |
| tpb | Title: Missing support for LFE5-12F devices · Issue #55 · SymbiFlow/prjtrellis · GitHub (at github.com) | 16:08 |
| flow | Ohh thank you so much :-) | 16:09 |
| flow | You saved the day! | 16:10 |
| *** flow has quit IRC | 16:11 | |
| *** kraiskil has quit IRC | 16:15 | |
| sf-slack | <acomodi> litghost: I have thought of many possible solutions for the connections problem in the equivalent tiles. Among all of them I have selected the one that I think could be the way to go. I have updated the document with a very high level description of the approach (under the Connection chapter) | 16:48 |
| litghost | acomodi: Thanks | 16:48 |
| litghost | acomodi: Did you write the alturnative approaches in the doc? | 16:48 |
| sf-slack | <acomodi> litghost: no, because they were unfeasible, I have tried to see whether they could be implemented but I ended up realizing that the complexity was too high and they required changes in all the VPR steps | 16:51 |
| litghost | acomodi: Please write them down, and a short reason why you didn't choose them | 16:51 |
| sf-slack | <acomodi> litghost: Ok | 16:52 |
| *** Vonter has joined #symbiflow | 17:07 | |
| sf-slack | <risto.pejasinovic> I am going through installation of prjxray. I can provide some notes for troubles I had on Arch Linux. I had to install libidn11 https://www.archlinux.org/packages/community/x86_64/libidn11/ . Also Vivado/SDK 2018.2 seems to have cmake 3.3.2 internaly. So if Vivado is sourced it overwrites system cmake. Anyway I have Vivado 2018.2 so I will have to rollback to 2017.2 because of | 17:11 |
| sf-slack | https://github.com/SymbiFlow/prjxray/issues/14 Let me know if this is usefull for you, I can provide further notes after I install old vivado. | 17:11 |
| tpb | Title: Arch Linux - libidn11 1.33-1 (x86_64) (at www.archlinux.org) | 17:11 |
| tpb | Title: MUXF8 vivado compatibility · Issue #14 · SymbiFlow/prjxray · GitHub (at github.com) | 17:11 |
| felix_ | sf-slack: the cmake issue was fixed in december https://github.com/SymbiFlow/prjxray/issues/415 don't source the vivado toolchain environment by yourself; prjxray will take care of that. i think i also did fix the documentation on that | 17:50 |
| tpb | Title: Wrong CMake version is used · Issue #415 · SymbiFlow/prjxray · GitHub (at github.com) | 17:50 |
| felix_ | yeah, it's in the readme | 17:52 |
| sf-slack | <risto.pejasinovic> Ok I see your change https://github.com/SymbiFlow/prjxray/pull/416 . | 17:58 |
| tpb | Title: introduce vivado wrapper by felixheld · Pull Request #416 · SymbiFlow/prjxray · GitHub (at github.com) | 17:58 |
| sf-slack | <risto.pejasinovic> Problem is that I had Vivado already installed, and I source it in .bash_profile. In readme it doesn't say explicitly that I should not have Vivado sourced before. | 17:59 |
| *** flow has joined #symbiflow | 18:07 | |
| *** flow has quit IRC | 18:11 | |
| felix_ | ah. yeah, sourcing the vivado environment in .bash_profile will likely break non-vivado things. i'll add that to the readme and send a pull request | 18:37 |
| sf-slack | <risto.pejasinovic> Yeah it was not the smartest idea. But warning in doc can be useful. | 18:43 |
| felix_ | yep | 18:43 |
| sf-slack | <acomodi> litghost: I have further elaborated my thoughts on the doc. I still need to verify whether this approach is doable, but I believe it is the right way to go. | 19:43 |
| *** kraiskil has joined #symbiflow | 20:08 | |
| *** kraiskil has quit IRC | 20:48 | |
| *** risto_ has joined #symbiflow | 20:49 | |
| *** risto_ has quit IRC | 20:50 | |
| litghost | acomodi: Design looks like it might work, you good to proceed with that design? | 20:57 |
| sf-slack | <risto.pejasinovic> I have read prjxray docs and run some fuzzers. I think I have an idea what is happening. Maybe someone could review my thinking. Idea is to provide FRAME (bitstream unit with address and configuration of primitive) for every primitive in FPGA. It is done by using vivado and instantiating primitives, fuzzer instantiate primitive in verilog and randomize(?) INIT values using tcl finaly provides address of | 21:49 |
| sf-slack | primitive. (Not completely clear yet how it works) Now I kinda understand your recommendations from earlier. @litghost (https://github.com/SymbiFlow/prjxray/issues/697) I guess 005-tilegrid fuzzer is used to find base address of every Tile? Maybe solving this is not enough for GSoC? @kgugala Figuring out which PS7 pin goes to which interconnect (PIP?). By PS7 port you mean like AXI interfaces, GPIOs etc... ? Having this Vivado | 21:49 |
| sf-slack | IP integrator can be avoided? This sounds to me like interesting and useful project for GSoC. But I dont know yet how would i tackle it. | 21:49 |
| tpb | Title: 005-tilegrid fails for Zynq 7020 · Issue #697 · SymbiFlow/prjxray · GitHub (at github.com) | 21:49 |
| litghost | risto.pejasinovic: You have the right idea. I don't expect that fixing the bug in the 7010 vs 7020 support will be that hard, but then taking zynq support past that (like you said AXI, etc) is something we haven't started on | 21:50 |
| mithro | Can someone make sure https://github.com/YosysHQ/yosys/pull/917 doesn't break Yosys+VPR? | 21:55 |
| tpb | Title: Fix retiming for synth_xilinx and for abc -dff by eddiehung · Pull Request #917 · YosysHQ/yosys · GitHub (at github.com) | 21:55 |
| sf-slack | <risto.pejasinovic> @litghost Nice, thank you. Maybe I could do proposal in 2 parts, first fix #697 and get familiar with the flow, then start working on PS7 and do as much as I can. Not sure if I have to be specific in proposal with progress? | 22:01 |
| litghost | risto.pejasinovic: I think a good goal might be to have a meaningful part of the design accessible from the ARM core. Like an AXI GPIO or UART or SPI, as concrete examples | 22:03 |
| litghost | risto.pejasinovic: Like you said, having reasonable intermediates might be fixing #697, making a blinky style design work on your target platform, and then some super basic ARM <-> fabric test | 22:04 |
| *** Maya-sama has joined #symbiflow | 22:04 | |
| *** Bertl_oO_ has joined #symbiflow | 22:08 | |
| *** Miyu has quit IRC | 22:09 | |
| *** Bertl_oO has quit IRC | 22:09 | |
| elms | litghost: Do you know if prjxray uses json5 for efficiency/speed reasons? | 22:14 |
| sf-slack | <risto.pejasinovic> @litghost Yeah that makes sense. Will start writing proposal now. | 22:15 |
| litghost | elms: json5 is used soley because json doesn't support trailing comma's | 22:15 |
| litghost | elms: And there is some streaming tcl code that doesn't look ahead to see if it is at the last item in a JSON list | 22:15 |
| litghost | elms: Someone could try to remove the use of trailing comma's, but I don't consider it of high priority | 22:16 |
| elms | litghost: ok thanks. No I was looking at something else and just saw json5, simplejson and json in different files. I'll open an issue to consolidate on using pyjson5 | 22:17 |
| litghost | elms: I think we should probably consolidate on the simplejson | 22:17 |
| litghost | elms: json5 is limited to one or two files | 22:17 |
| *** Bertl_oO_ is now known as Bertl | 22:21 | |
| duck2 | fyi, pyjson5 is the only library in arch-defs and prjxray which doesn't support pypy | 22:22 |
| elms | litghost: but we'd have to remove the trailing comma then. Also I think simplejson is only needed if you want to be compatible with older python versions. If we fix the trailing commas we can just use json module | 22:23 |
| litghost | elms: Has the default json module gotten faster? | 22:24 |
| elms | duck2: yeah. Ideally we would not need it. I'll add that to the issue. | 22:24 |
| elms | litghost: I have no data on that. I'll add a comment to the issue. | 22:25 |
| mithro | tansell@tansell-glaptop:~/github/SymbiFlow/prjxray-db/artix7$ du -h -s tileconn.json* tilegrid.json* | 23:01 |
| mithro | 244Ktileconn.json.bz2 | 23:01 |
| mithro | 96Ktilegrid.json.bz2 | 23:01 |
| mithro | elms: What has trailing commas? | 23:01 |
| elms | 15:07 <litghost> elms: And there is some streaming tcl code that doesn't look ahead to see if it is at the last item in a JSON list | 23:02 |
| elms | mithro: ^^ | 23:02 |
| mithro | elms: I'm pretty sure I've solved this problem previously - hold on a sec | 23:03 |
| elms | mithro: I haven't confirmed. Just was noticing 3 different json imports in the code | 23:03 |
| mithro | Hrm.. Actually it looks like that was comments at the start / end of json files it seems | 23:04 |
| mithro | https://github.com/mithro/rcfiles/blob/master/bin/json_pp | 23:04 |
| tpb | Title: rcfiles/json_pp at master · mithro/rcfiles · GitHub (at github.com) | 23:04 |
| mithro | There also seems to be https://pypi.org/project/jsoncomment/ | 23:05 |
| tpb | Title: jsoncomment · PyPI (at pypi.org) | 23:05 |
| elms | Yeah I referenced that in the issue. Looks like that and ujson may be worth exploring. | 23:06 |
| elms | but it's not a squeaky wheel at the moment. Just putting it on the backlog. | 23:06 |
| mithro | duck2: See my comment on your proposal about the tileconn/tilegrid verse rr_graph stuff | 23:08 |
| mithro | Anyway, going back to putting together furniture! | 23:09 |
| duck2 | mithro: i have already replied :p | 23:11 |
| mithro | duck2: I'll look again later today | 23:15 |
| duck2 | mithro: ok | 23:19 |
| *** Miyu has joined #symbiflow | 23:31 | |
| *** Maya-sama has quit IRC | 23:31 | |
| *** _whitelogger has quit IRC | 23:40 | |
| *** _whitelogger has joined #symbiflow | 23:43 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!