<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
<duck2>
kind of divides the project into two projects.
_whitelogger has joined #symbiflow
<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
<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?
<mithro>
zeigren[m]: I'm not sure that would be a high priority project at the moment
<hackerfoo>
That should cover all Linux distros and MacOS.
<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!
citypw has joined #symbiflow
<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
<mithro>
Improving sphinx by adding verilog support would be a good project
<mithro>
Testing on hardware would be interesting
<mithro>
A html+javascript graphical viewer for the databases and chipdb would be good too
_whitelogger has joined #symbiflow
Bertl_oO is now known as bertl_zZ
_whitelogger has joined #symbiflow
<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?
OmniMancer has joined #symbiflow
_whitelogger has joined #symbiflow
<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.
<tpb>
Title: Create a really good library for parsing / producing SDF files · Issue #17 · SymbiFlow/ideas · GitHub (at github.com)
Sha has joined #symbiflow
sf-slack has quit [Remote host closed the connection]
sf-slack has joined #symbiflow
_whitelogger has joined #symbiflow
Sha has quit [Ping timeout: 256 seconds]
zeigren[m] has quit [Remote host closed the connection]
xobs has quit [Read error: Connection reset by peer]
mrhat2010[m] has quit [Remote host closed the connection]
galv[m] has quit [Remote host closed the connection]
galv[m] has joined #symbiflow
xobs has joined #symbiflow
zeigren[m] has joined #symbiflow
mrhat2010[m] has joined #symbiflow
OmniMancer has quit [Quit: Leaving.]
kraiskil has joined #symbiflow
lopsided98 has quit [Ping timeout: 250 seconds]
lopsided98_ has joined #symbiflow
<sf-slack>
<kgugala> Hi @christiansen.daniel those tools are already in progress
<tpb>
Title: integrate other documentations into this top-level documentation · Issue #3 · SymbiFlow/symbiflow-docs · GitHub (at github.com)
<sf-slack>
<mgielda> @me1 plz comment
kraiskil has joined #symbiflow
<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
<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.
<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
<sf-slack>
<kgugala> but at least glossary should be ;)
<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?
<sorear>
What do you mean?
<daveshah>
There is already ECP5 support, it's just not very public for reasons
<flow>
I just setup the nextpnr toolchain and it only showed support for the LFE5-25, LFE5-45 and LFE5-85
<daveshah>
Yes, those are the three ECP5 die variants
<tpb>
Title: Missing support for LFE5-12F devices · Issue #55 · SymbiFlow/prjtrellis · GitHub (at github.com)
<flow>
Ohh thank you so much :-)
<flow>
You saved the day!
flow has quit [Quit: Page closed]
kraiskil has quit [Ping timeout: 245 seconds]
<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)
<litghost>
acomodi: Thanks
<litghost>
acomodi: Did you write the alturnative approaches in the doc?
<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
<litghost>
acomodi: Please write them down, and a short reason why you didn't choose them
<sf-slack>
<acomodi> litghost: Ok
Vonter has joined #symbiflow
<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
<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
<tpb>
Title: Wrong CMake version is used · Issue #415 · SymbiFlow/prjxray · GitHub (at github.com)
<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.
flow has joined #symbiflow
flow has quit [Ping timeout: 256 seconds]
<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
<sf-slack>
<risto.pejasinovic> Yeah it was not the smartest idea. But warning in doc can be useful.
<felix_>
yep
<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.
kraiskil has joined #symbiflow
kraiskil has quit [Ping timeout: 246 seconds]
risto_ has joined #symbiflow
risto_ has quit [Client Quit]
<litghost>
acomodi: Design looks like it might work, you good to proceed with that design?
<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
<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
<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.
<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
<tpb>
Title: Fix retiming for synth_xilinx and for abc -dff by eddiehung · Pull Request #917 · YosysHQ/yosys · GitHub (at github.com)
<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?
<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
<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
Maya-sama has joined #symbiflow
Bertl_oO_ has joined #symbiflow
Miyu has quit [Ping timeout: 246 seconds]
Bertl_oO has quit [Ping timeout: 246 seconds]
<elms>
litghost: Do you know if prjxray uses json5 for efficiency/speed reasons?
<sf-slack>
<risto.pejasinovic> @litghost Yeah that makes sense. Will start writing proposal now.
<litghost>
elms: json5 is used soley because json doesn't support trailing comma's
<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
<litghost>
elms: Someone could try to remove the use of trailing comma's, but I don't consider it of high priority
<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
<litghost>
elms: I think we should probably consolidate on the simplejson
<litghost>
elms: json5 is limited to one or two files
Bertl_oO_ is now known as Bertl
<duck2>
fyi, pyjson5 is the only library in arch-defs and prjxray which doesn't support pypy
<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
<litghost>
elms: Has the default json module gotten faster?
<elms>
duck2: yeah. Ideally we would not need it. I'll add that to the issue.
<elms>
litghost: I have no data on that. I'll add a comment to the issue.
<mithro>
tansell@tansell-glaptop:~/github/SymbiFlow/prjxray-db/artix7$ du -h -s tileconn.json* tilegrid.json*
<mithro>
96Ktilegrid.json.bz2
<mithro>
244Ktileconn.json.bz2
<mithro>
elms: What has trailing commas?
<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
<elms>
mithro: ^^
<mithro>
elms: I'm pretty sure I've solved this problem previously - hold on a sec
<elms>
mithro: I haven't confirmed. Just was noticing 3 different json imports in the code
<mithro>
Hrm.. Actually it looks like that was comments at the start / end of json files it seems