03:06 <umarcor> kamyar: nice to meet you! Are you aware of https://umarcor.github.io/osvb/apis/core.html and https://umarcor.github.io/osvb/apis/tool.html ? I believe those can be inspiring for your proposal.

03:06 <tpb> Title: Core Open Source Verification Bundle latest documentation (at umarcor.github.io)

03:08 <umarcor> kamyar: furthermore, I'd be very interested in having feedback from you, because I've talked to authors/maintainers of Edalize, PyFPGA, VUnit, pyIPCMI and tsfpga, but you (Xeda) are missing in my knowledge!

03:15 <umarcor> kamyar: I cannot edit/comment on your gdoc, so I'll comment here. Bash is available on Windows (actually, several flavours of it). Hence, current SymbiFlow scripts are not limited to Linux because of that reason.

03:19 <umarcor> getting rid of all non-python scripts might be not possible in practice. Both Edalize and PyFPGA do code generation (TCL/Makefiles). Although I might agree they probably "abuse" the possibility, I think there might be good reason for doing it.

03:22 <umarcor> Overall, I feel that converting SymbiFlow scripts to Xeda might be strategically very benefitial for Xeda, but not so much for SymbiFlow. In my humble opinion, the proposal would be much stronger if you used your prior knowledge about Xeda as a foundation, but not a condition (i.e. explicit outcome).

05:30 <sf-slack> <khanvms9> I checked it, it is not applicable in olofk/edalize.

05:36 <sf-slack> <khanvms9> To upstream the changes do I need to study other projects like fpga-tool-perf or knowing the edalize project is enough?

08:10 <_whitenotifier-5> [fpga-interchange-schema] gatecat opened issue #34: UltraScale clock routing - https://git.io/JO3pT

09:51 <sf-slack> <acomodi> I think that information on how fpga-tool-perf uses Edalize would be required to understand what needs to be upstreamed

12:44 <sf-slack> <khanvms9> Ok got it

14:17 <mithro> Hi CarlosEDP!

14:37 <mithro> cr1901_modern: Are you around?

14:40 <mithro> cr1901_modern: I think I just had an epiphany around some implicit knowledge about how VPR / symbiflow / etc works that is never really explained

14:40 <cr1901_modern> mithro: Yes, I am around

14:41 <cr1901_modern> Yesterday I needed to restart and somehow forgot to rejoin the channel

14:42 <mithro> https://docs.google.com/drawings/d/1osrFz9VOWvQuOGMyEwh3KA-Na2gGIL1k-511SUFSE3I/edit

14:42 <tpb> Title: Tool and architecture divide in SymbiFlow - Google Zeichnungen (at docs.google.com)

14:46 <cr1901_modern> You have skill w/ Google Docs :P

14:46 <mithro> cr1901_modern: I'm not sure that is a compliment ;-)

14:48 <cr1901_modern> was meant as one :)

14:49 <cr1901_modern> I think I get the gist of symbiflow, it's just putting everything into the build system that's difficult. The ice40 backend has been the easiest way for me to get started.

14:49 <cr1901_modern> But overwhelmingly I've been told "the xc7 backend is what you should look at"

14:49 <mithro> cr1901_modern: At some point I think we will take another stab at the build system

14:49 <mithro> xc7 backend is the most used / tested / etc

14:50 <cr1901_modern> But the xc7 backend has A LOT of stuff that I honestly don't need, and it's clear that multiple people worked on integrating it into the build system over time

14:50 <cr1901_modern> As opposed to me, a single person who just wants something that works to start out with

14:51 <CarlosEDP> <mithro "Hi CarlosEDP!"> Hi Tim! Thanks for the invite!

14:51 <cr1901_modern> Like, I don't mind eventually structuring machxo2 as xc7, but right now, I have a single device and single dev board. And the cmake files for adding a device and dev board in xc7 backend are hundreds of lines meant to abstract things away

14:52 <cr1901_modern> nextpnr doesn't have this problem by virtue of "that level of abstraction just hasn't happened yet" :P

14:52 <CarlosEDP> I also found that the 7series flow is way more complex than the ICE40 or ECP5 ones... still studying it tho

14:52 <mithro> cr1901_modern: I think I sometimes forget that some people are not comfortable working in systems that they only barely understand

14:53 <cr1901_modern> Well, also part of it is I feel like I'm bitching too much and I keep my concerns to myself

14:53 <CarlosEDP> on Lattice, you just "build yosys, build nextpnr, build trellis or icestorm" and done

14:53 <mithro> cr1901_modern: But ultimately that is everything these days

14:54 <cr1901_modern> mithro: This is all long-winded way of saying "I don't know how to create a quickstart for adding a new arch to symbiflow, and there's A LOT of cmake code I have to read to get to that point that distracts me from getting something that works and can be integrated better later."

14:54 <cr1901_modern> E.g. the arch() function is HUGE

14:54 <mithro> cr1901_modern: So copy an existing one and ignore most of it?

14:55 <cr1901_modern> That's what I did w/ ice40 :P

14:55 <cr1901_modern> Because all the important stuff is in a single file ;)

14:58 <cr1901_modern> I think this sums it up: http://ix.io/2W2W

14:59 <cr1901_modern> Anyways, I'm still studying the build system to figure out what I should work on next

15:00 <mithro> cr1901_modern: I think one of the important things in symbiflow-arch-defs is that it tries to make it possible to validate your results against the vendor tools in numerous ways

15:00 <mithro> I shared https://docs.google.com/document/d/11wJUvr2aVBkUiuYYsFN07jkoYr_ccWlLLLFH8YQw8uQ/edit#heading=h.uuw1jptahpuu with you right?

15:00 <tpb> Title: SymbiFlow Checking / Testing Approach - Google Docs (at docs.google.com)

15:01 <cr1901_modern> Yes you did

15:02 <mithro> Also, we try to do as little manual testing as possible because manual testing is not reproducible :-)

15:05 <cr1901_modern> Well, the yosys equiv* passes will help at least