Friday, 2019-04-05

*** tpb has joined #symbiflow00:00
*** _whitelogger has joined #symbiflow00:01
mithrokgugala: 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
tpbTitle: python-sdf-timing/tests/data at master · SymbiFlow/python-sdf-timing · GitHub (at github.com)00:38
*** _whitelogger has quit IRC00:46
*** _whitelogger has joined #symbiflow00:49
duck2mithro: 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 it01:11
duck2 kind of divides the project into two projects.01:11
*** _whitelogger has quit IRC02:22
*** _whitelogger has joined #symbiflow02: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 their02: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
mithrozeigren[m]: I'm not sure that would be a high priority project at the moment03:15
*** _whitelogger has quit IRC03:34
*** _whitelogger has joined #symbiflow03:37
hackerfoozeigren[m]: I'd like to get everything into Nixpkgs: https://github.com/NixOS/nixpkgs03:50
tpbTitle: GitHub - NixOS/nixpkgs: Nix Packages collection (at github.com)03:50
hackerfooThat 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 #symbiflow04: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/ideas04:21
mithroImproving sphinx by adding verilog support would be a good project04:23
mithroTesting on hardware would be interesting04:28
mithroA html+javascript graphical viewer for the databases and chipdb would be good too04:30
*** _whitelogger has quit IRC04:43
*** _whitelogger has joined #symbiflow04:46
*** Bertl_oO is now known as bertl_zZ04:57
*** _whitelogger has quit IRC05:07
*** _whitelogger has joined #symbiflow05: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 #symbiflow05:26
*** _whitelogger has quit IRC05:37
*** _whitelogger has joined #symbiflow05: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
tpbTitle: Create a really good library for parsing / producing SDF files · Issue #17 · SymbiFlow/ideas · GitHub (at github.com)05:42
*** Sha has joined #symbiflow05:44
*** sf-slack has quit IRC06:04
*** sf-slack has joined #symbiflow06:04
*** _whitelogger has quit IRC06:25
*** _whitelogger has joined #symbiflow06:28
*** Sha has quit IRC06:33
*** mrhat2010[m] has quit IRC06:39
*** zeigren[m] has quit IRC06:39
*** xobs has quit IRC06:39
*** galv[m] has quit IRC06:39
*** galv[m] has joined #symbiflow06:50
*** zeigren[m] has joined #symbiflow07:21
*** xobs has joined #symbiflow07:21
*** mrhat2010[m] has joined #symbiflow07:21
*** OmniMancer has quit IRC07:37
*** kraiskil has joined #symbiflow07:37
*** lopsided98 has quit IRC08:11
*** lopsided98_ has joined #symbiflow08:11
sf-slack<kgugala> Hi @christiansen.daniel those tools are already in progress08:15
sf-slack<kgugala> see https://github.com/SymbiFlow/python-sdf-timing08:15
tpbTitle: 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/70608:16
tpbTitle: 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 tool08:17
sf-slack<kgugala> right now it generates what was needed for the BEL timing fuzzer08:18
sf-slack<kgugala> and I didn't test it very extensively08:18
sf-slack<kgugala> so there are some issues to address here08:18
*** kraiskil has quit IRC08:35
*** kraiskil has joined #symbiflow08:56
*** kraiskil has quit IRC09:01
*** citypw has quit IRC09:02
*** futarisIRCcloud has quit IRC09:04
*** kraiskil has joined #symbiflow09:14
*** i8hantanu has joined #symbiflow09:30
*** futarisIRCcloud has joined #symbiflow09:40
*** zeigren[m] has quit IRC10:01
*** mrhat2010[m] has quit IRC10:01
*** galv[m] has quit IRC10:01
*** xobs has quit IRC10:01
*** galv[m] has joined #symbiflow10:11
*** zeigren[m] has joined #symbiflow10:39
*** xobs has joined #symbiflow10:39
*** mrhat2010[m] has joined #symbiflow10:39
*** citypw has joined #symbiflow11:09
*** ipieter has joined #symbiflow11:36
*** bertl_zZ is now known as Bertl12:22
*** ipieter has quit IRC12:35
*** kraiskil has quit IRC13:05
*** kraiskil has joined #symbiflow13:22
*** futarisIRCcloud has quit IRC13:59
*** i8hantanu has quit IRC14: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/53714:12
tpbTitle: WIP: Tile grid location mapping by mkurc-ant · Pull Request #537 · SymbiFlow/symbiflow-arch-defs · GitHub (at github.com)14:12
*** kraiskil has quit IRC14:26
*** Bertl is now known as Bertl_oO14:58
sf-slack<mgielda> https://github.com/SymbiFlow/symbiflow-docs/issues/315:13
tpbTitle: integrate other documentations into this top-level documentation · Issue #3 · SymbiFlow/symbiflow-docs · GitHub (at github.com)15:13
sf-slack<mgielda> @me1 plz comment15:13
*** kraiskil has joined #symbiflow15: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 from15:42
sf-slackabove. 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
tpbTitle: 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 date15:44
sf-slack<kgugala> but at least glossary should be ;)15:44
sf-slack<risto.pejasinovic> @kgugala Thanks, noted.15:56
*** flow has joined #symbiflow15:59
flowHey, 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
sorearWhat do you mean?16:06
daveshahThere is already ECP5 support, it's just not very public for reasons16:07
flowI just setup the nextpnr toolchain and it only showed support for the LFE5-25, LFE5-45 and LFE5-8516:07
daveshahYes, those are the three ECP5 die variants16:07
flowhttps://www.digikey.com/product-detail/en/lattice-semiconductor-corporation/LFE5U-12F-7BG256C/LFE5U-12F-7BG256C-ND/955393016:08
tpbTitle: LFE5U-12F-7BG256C Lattice Semiconductor Corporation | Integrated Circuits (ICs) | DigiKey (at www.digikey.com)16:08
daveshahhttps://github.com/SymbiFlow/prjtrellis/issues/5516:08
tpbTitle: Missing support for LFE5-12F devices · Issue #55 · SymbiFlow/prjtrellis · GitHub (at github.com)16:08
flowOhh thank you so much :-)16:09
flowYou saved the day!16:10
*** flow has quit IRC16:11
*** kraiskil has quit IRC16: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
litghostacomodi: Thanks16:48
litghostacomodi: 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 steps16:51
litghostacomodi: Please write them down, and a short reason why you didn't choose them16:51
sf-slack<acomodi> litghost: Ok16:52
*** Vonter has joined #symbiflow17: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 of17:11
sf-slackhttps://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
tpbTitle: Arch Linux - libidn11 1.33-1 (x86_64) (at www.archlinux.org)17:11
tpbTitle: 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 that17:50
tpbTitle: Wrong CMake version is used · Issue #415 · SymbiFlow/prjxray · GitHub (at github.com)17:50
felix_yeah, it's in the readme17:52
sf-slack<risto.pejasinovic> Ok I see your change https://github.com/SymbiFlow/prjxray/pull/416 .17:58
tpbTitle: 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 #symbiflow18:07
*** flow has quit IRC18: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 request18:37
sf-slack<risto.pejasinovic> Yeah it was not the smartest idea. But warning in doc can be useful.18:43
felix_yep18: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 #symbiflow20:08
*** kraiskil has quit IRC20:48
*** risto_ has joined #symbiflow20:49
*** risto_ has quit IRC20:50
litghostacomodi: 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 of21:49
sf-slackprimitive. (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 Vivado21:49
sf-slackIP 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
tpbTitle: 005-tilegrid fails for Zynq 7020 · Issue #697 · SymbiFlow/prjxray · GitHub (at github.com)21:49
litghostristo.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 on21:50
mithroCan someone make sure https://github.com/YosysHQ/yosys/pull/917 doesn't break Yosys+VPR?21:55
tpbTitle: 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
litghostristo.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 examples22:03
litghostristo.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 test22:04
*** Maya-sama has joined #symbiflow22:04
*** Bertl_oO_ has joined #symbiflow22:08
*** Miyu has quit IRC22:09
*** Bertl_oO has quit IRC22:09
elmslitghost: 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
litghostelms: json5 is used soley because json doesn't support trailing comma's22:15
litghostelms: And there is some streaming tcl code that doesn't look ahead to see if it is at the last item in a JSON list22:15
litghostelms: Someone could try to remove the use of trailing comma's, but I don't consider it of high priority22:16
elmslitghost: 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 pyjson522:17
litghostelms: I think we should probably consolidate on the simplejson22:17
litghostelms: json5 is limited to one or two files22:17
*** Bertl_oO_ is now known as Bertl22:21
duck2fyi, pyjson5 is the only library in arch-defs and prjxray which doesn't support pypy22:22
elmslitghost: 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 module22:23
litghostelms: Has the default json module gotten faster?22:24
elmsduck2: yeah. Ideally we would not need it. I'll add that to the issue.22:24
elmslitghost: I have no data on that. I'll add a comment to the issue.22:25
mithro[email protected]:~/github/SymbiFlow/prjxray-db/artix7$ du -h -s tileconn.json* tilegrid.json*23:01
mithro244Ktileconn.json.bz223:01
mithro96Ktilegrid.json.bz223:01
mithroelms: What has trailing commas?23:01
elms15: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 list23:02
elmsmithro: ^^23:02
mithroelms: I'm pretty sure I've solved this problem previously - hold on a sec23:03
elmsmithro: I haven't confirmed. Just was noticing 3 different json imports in the code23:03
mithroHrm.. Actually it looks like that was comments at the start / end of json files it seems23:04
mithrohttps://github.com/mithro/rcfiles/blob/master/bin/json_pp23:04
tpbTitle: rcfiles/json_pp at master · mithro/rcfiles · GitHub (at github.com)23:04
mithroThere also seems to be https://pypi.org/project/jsoncomment/23:05
tpbTitle: jsoncomment · PyPI (at pypi.org)23:05
elmsYeah I referenced that in the issue. Looks like that and ujson may be worth exploring.23:06
elmsbut it's not a squeaky wheel at the moment. Just putting it on the backlog.23:06
mithroduck2: See my comment on your proposal about the tileconn/tilegrid verse rr_graph stuff23:08
mithroAnyway, going back to putting together furniture!23:09
duck2mithro: i have already replied :p23:11
mithroduck2: I'll look again later today23:15
duck2mithro: ok23:19
*** Miyu has joined #symbiflow23:31
*** Maya-sama has quit IRC23:31
*** _whitelogger has quit IRC23:40
*** _whitelogger has joined #symbiflow23:43

Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!