00:49 <mithro> jfierro: The hope is someone will work on them :-P

00:49 <mithro> Anyone seen https://ggeditor.readthedocs.io/en/latest/index.html before? Seems like it could be a way to get some of our many Google Docs into ReadTheDocs / Git Repo

00:49 <tpb> Title: GGeditor GGEditor documentation (at ggeditor.readthedocs.io)

00:49 <mithro> @rwinkler: See above

01:03 <mithro> Hi andrewb1999 !

01:07 <andrewb1999> Hi mithro and everyone else!

01:08 <andrewb1999> Looking forward to participating in summer of code!

01:09 <mithro> https://summerofcode.withgoogle.com/organizations/6224851964002304/#projects

01:09 <jfierro> Hi andrew!

01:14 <mithro> andrewb1999: Excited to have you working on partial reconfiguration support for SymbiFlow!

01:29 <rtpg> Hi, I was linked to this project while looking at open source options for programming on a basys 3. My project currently uses system verilog, and yosys seems to say that only a small subset of system verilog is supported. Would anyone know what the extent of that support is?

01:31 <jfierro> From my own experience, very little unfortunately :(

01:32 <jfierro> rtpg: But I believe there is an open source SystemVerilog to verilog converter, though I have not personally used it.

01:33 <rtpg> Ah, I might be OK with that. Personally I don't know how people handle verilog without at least structs

01:33 <rtpg> Ah I guess people use macros instead for that :)

01:34 <mithro> rtpg: Or use something like nmigen

01:34 <rtpg> I'm still a bit of an FPGA beginner but being able to just stay inside emacs for everything and not having to sign export agreements for everything is very tempting, so will try and see if I can get my stuff working through _some_ sort of pipeline

01:35 <jfierro> https://github.com/SymbiFlow/sv-tests might have just what you're looking for.

01:35 <tpb> Title: GitHub - SymbiFlow/sv-tests: Test suite designed to check compliance with the SystemVerilog standard. (at github.com)

01:36 <rtpg> ah nmigen looks very cool. Plus it's "Just Python" which is basically my language of choice

01:38 <rtpg> Oh, I was also wondering, is there something equivalent to pytest for building out test suites? I have a couple test benches but I just run them by hand one by one and would like to build out regression tests

01:38 <mithro> rtpg: cocotb or vunit might be what you are looking for

01:38 <mithro> rtpg: There isn't really a "standard" however

01:39 <rtpg> wow, these both look very much like what I was looking for! Thanks a lot

01:40 <rtpg> or at least something in this nature, I don't have a lot of existing code just yet so I can adapt to whatever tools need

01:41 <rtpg> OK, I think I'll start out trying to automate my test benches then will think about how to tackle my other stuff

01:42 <jfierro> While we're on this topic, something I've been meaning to ask is what is the interest in supporting more SV in yosys? I know there's a commercial option that integrates with verific, but I'm wondering if this is simply too much work for the project to care about right now.

01:43 <jfierro> sv_parser has some impressive coverage numbers but it's written in rust, so it would need a C++ binding probably. Also I don't know if yosys bindings for verific are too tied to verific-specific stuff.

01:47 <jfierro> Ah, there's surelog as well.

08:43 <sf-slack2> <pgielda> https://github.com/antmicro/yosys/tree/uhdm-yosys

08:43 <tpb> Title: GitHub - antmicro/yosys at uhdm-yosys (at github.com)

08:43 <sf-slack2> <pgielda> There is some work on uhdm frontend

08:44 <sf-slack2> <pgielda> very early stage

15:15 <_whitenotifier-9> [symbiflow-arch-defs] rw1nkler opened issue #1465: "OpenTitan RTL synthesis with Yosys" in hardenedlinux - https://git.io/JfGxw

18:14 <hackerfoo> I have data showing a standard deviation of 10-20% (depending on measure) in run time, for the same test on the same machine (at roughly the same time), without any apparent reason (no swap, plenty of RAM, idle cores.)

18:15 <hackerfoo> This means we'd need 400-500 runs to be 95% confident to 1-2%.

18:18 <hackerfoo> I'm just going to stop worrying about small variances in runtime, I guess.

18:53 <hackerfoo> *the same machine type, not necessarily the same machine.

19:03 <hackerfoo> https://colab.research.google.com/drive/1EMMHd1UJpKIfu-PfXRmjg5q-6zf1a9yx

21:02 <daveshah> I don't know if you have any low level access to the machine, but I wonder if turning off any turbo boost type features might reduce deviation?

21:32 <hackerfoo> daveshah: Good idea. Unfortunately, I can't find a way to disable turbo.

21:35 <hackerfoo> The all-core vs. single core turbo frequencies for the machine I'm using exactly match the width of the distribution in the above chart.

21:35 <hackerfoo> So that probably explains it.