00:43 <sf-slack> <jake.mercer> I'm looking to get started contributing to project x-ray; are there active areas that would be best to focus on?

00:45 <sf-slack> <jake.mercer> I have a Kintex board here also, but I don't think the free Xilinx license will cover it; I was using it a few years ago on the university program.

00:46 <litghost> Hi jake! If you have interest on documenting the DSP, we lack many fuzzers around that. If you have particular interests, I can suggest what you can do that aligns with your interests

00:48 <sf-slack> <jake.mercer> DSP sounds good to me, I'll have to sink my teeth into the Xilinx docs first though, it's been a while :,)

00:50 <litghost> jake: Of course! The first fuzzer that would be good to get you started is attempting to document DSP attributes

00:50 <litghost> We have an existing fuzzer that documents the MASK and PATTERN attributes here https://github.com/SymbiFlow/prjxray/tree/master/fuzzers/100-dsp-mskpat

00:51 <tpb> Title: prjxray/fuzzers/100-dsp-mskpat at master · SymbiFlow/prjxray · GitHub (at github.com)

00:51 <litghost> You could work on adding fuzzing for the other attributes documented in https://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug953-vivado-7series-libraries.pdf for the DSP48E1, using that fuzzer as a model

00:53 <sf-slack> <jake.mercer> Okay, sounds like a plan!:)

00:57 <litghost> Word of warning, we are currently using a particular Vivado version, 2017.2. This is covered in the prjxray README, but I want to point it out as it sometimes gets missed

01:01 <sf-slack> <jake.mercer> Yes, I did notice that, I'm currently following the README and bringing up a VM. Just out of interest, why is it frozen at 2017.2? Is it for stability reasons?

01:01 <litghost> Stability is a major reason

01:02 <litghost> For example, 2017.2 supports the LUT6_2 primative, which is very useful for constraining how Vivado packs a SLICEL. I believe this is removed in later versions?

01:03 <litghost> Anyways, we found that the existing fuzzers sometimes emit verilog that later versions of Vivado do not accept. We've stayed focused on expanding the documentation, rather than updating to a later version of Vivado

01:04 <litghost> If you were interested in debugging the reasons why some fuzzers do not work on the later versions of Vivado, we would love to accept patches

01:04 <litghost> It just has been easier (and so far without problem) to stay frozen at 2017.2

01:05 <litghost> For better or worse, the fuzzing process is very slow, and targetting more than one Vivado version would do nothing happy to the runtime of testing the fuzzers :)

01:05 <sf-slack> <jake.mercer> Interesting that they would remove functionality, I remember having a multitude of issues when I migrated from ISE to Vivado. Fair enough :) freezing it does make the most sense

01:06 <sf-slack> <jake.mercer> When I get this VM set up, do you think it would be worth sharing the .ova online? Might make it a bit easier to get up and running?

01:08 <litghost> jake: I'm unfamiliar with what an ".ova" is, but clear instructions on using it and adding a markdown document explaining how to use it would be fine

01:10 <sf-slack> <jake.mercer> It's just a virtual machine image file, so it would be Ubuntu 16.04 with Vivado already installed, and someone new would be able to download and run the virtual machine, so it would mean they could skip the install steps

02:07 <hackerfoo> jake.mercer: I'd like to get everything packaged for Nix. I got some things done.

02:07 <hackerfoo> But it's just whatever I need to develop on NixOS at the moment, since I can't devote any time to it.

02:09 <hackerfoo> If I knew someone would use it, I

02:09 <hackerfoo> I'd put more time into it.

02:10 <sf-slack> <jake.mercer> Is that including packaging up Vivado?

02:10 <sf-slack> <jake.mercer> Because that's easily the most annoying step IMO

02:10 <hackerfoo> Someone else did that already for 2017.2, although I have a .nix for 2019.1 as well.

02:11 <hackerfoo> Getting the tarball in the Nix store is a little tricky, but I have a script for it.

02:11 <hackerfoo> https://github.com/lukaslaobeyer/nix-fpgapkgs

02:11 <tpb> Title: GitHub - lukaslaobeyer/nix-fpgapkgs: Nix channel with FPGA development tools (at github.com)

02:12 <sf-slack> <jake.mercer> I've never used Nix before but that looks like a great idea

02:12 <hackerfoo> https://github.com/HackerFoo/hackerfoo-go-functions/blob/master/functions/nixos#L35-L47

02:12 <tpb> Title: hackerfoo-go-functions/nixos at master · HackerFoo/hackerfoo-go-functions · GitHub (at github.com)

02:12 <hackerfoo> It works really well, but other people break stuff from time to time. Conda is a big pain.

02:17 <hackerfoo> Here's what I have for working on symbiflow-arch-defs: https://gist.github.com/HackerFoo/74ae81405e191eb17b2675b28fcd6a94

02:17 <tpb> Title: sf-shell.nix · GitHub (at gist.github.com)

02:17 <hackerfoo> Obviously hacked up, but it works.

02:18 <hackerfoo> For me, at least.

02:19 <sf-slack> <jake.mercer> I must admit I don't really know what I'm looking at, but it Nix sounds pretty interesting so I'll do a bit of reading up on it

02:20 <sf-slack> <jake.mercer> If it lowers the barrier to entry for this stuff then it's a good thing in my book:)

10:48 <lromor[m]> Hello, small question, why the make targets are targeting basys3 and arty given the same xc7a50t chip? Even if the boards would break out the chip pins in different ways, shouldn't that differ only in the pcf file?

14:16 <litghost> lromor: Correct, it is a side affect of the ROI

14:16 <litghost> Currently we modify the routing graph with the synthetic connections to the roi

14:17 <litghost> once the roi harness is removed, basys3 and arty can share arch and routing graphs

14:45 <lromor[m]> Thank you!

18:12 <sf-slack> <jake.mercer> Okay, I've now got a setup up and running, had to make a few changes to what was in the README and requirements.txt, if someone else wants to try the above script on Ubuntu 16.04?

18:13 <sf-slack> <jake.mercer>

18:13 <litghost> jake: If the README is out of date, please do submit documentation updates

18:14 <sf-slack> <jake.mercer> I'm not sure if the above changes are correct as I'm new to the project, but I'll submit a PR

18:15 <litghost> jake: Either way, create a PR. If the changes are not correct, they could still point to updates needed in the docs

18:15 <sf-slack> <jake.mercer> Dead on:)

22:08 <mithro> kgugala: Can you access duck2's slides and my slides?

22:37 <sf-slack> <kgugala> @mithro yes, I can access both

22:54 <mithro> kgugala: So the idea is that a bunch of the description about how VtR / SymbiFlow Architecture definitions work lays the foundations for duck2's talk

22:58 <sf-slack> <kgugala> makes sense

23:12 <mithro> kgugala: Duck2 only has 3 minutes, so he won't have any time to really go into the background

23:24 <mithro> kgugala: I'm going to head to bed now - do you see the direction I was saying your slides should go in?