02:40 <synaption[m]> I think what I mean is a mostly portable bunch of libraries that everybody uses, and compiling and uploading is as easy as selecting a com port and hitting upload.

02:40 <synaption[m]> no barrier to entry?

04:09 <synaption[m]> a handful of widely used well documented boards

04:11 <synaption[m]> extensive example code built into an IDE, blink, button ect

09:20 <cjwfirmware> Hi all. Does anyone know the state of PCIe support in Symbiflow? Is anyone working on it, or close to getting it working?

13:51 <freemint> good morning from Japan Regenaxer

19:31 <owlhawk> I'm stuck on an issue with the 016-clb-noutmux fuzzer when targeting spartan7. Don't want too waste much of anyone's time on this, but thought I'd ask in case there's a simple answer.

19:32 <owlhawk> Vivado gives warnings similar to this: "CRITICAL WARNING: [Constraints 18-5] Cannot loc instance 'roi/clb_0/myLUT8/mux7a' at site SLICE_X18Y0, Shape is trying to block loc SLICE_X18Y0.A6LUT, however cell roi/clb_0/myLUT8/luta/LUT6 is already placed at this location" for every slice. It also complains about mux7b and mux8 in the same way.

19:33 <owlhawk> Looking at the fuzzer code, this placement seems to be intentional. So I'm not sure why vivado is complaining or how to attempt a workaround

20:14 <renze> Hello! Can someone point me to a good example of using an SGMII ethernet interface using the open toolchain? I have an ECP5 versa-5g board.

20:16 <sf-slack> <kgugala> @chris which vivado version are you using? Do you have you WIP code published somewhere?

20:24 <owlhawk> kgugala: I'm using version 2018.2. Code isn't published right now, but I'll see if I can get it up on github tonight.

20:25 <owlhawk> I haven't modified the clb-noutmux fuzzer at all, but it's possible that changes I've made in tilegrid or elsewhere are causing problems

20:26 <sf-slack> <kgugala> @chris please try 2017.2 - this one is known to work with the other parts

20:27 <cjwfirmware> Hi all

20:28 <sf-slack> <kgugala> @chris newer versions cause more trouble in fuzzers - they are more strict so some scripts may fail

20:29 <cjwfirmware> I was around last night, but I think it was too late for people. Do anyone know the state of PCIe in symbiflow right now? Does anyone know how close it is?

20:29 <cjwfirmware> I've looked around the web a bit, but it wasn't clear. Depending on its current state, I might be interested in getting it up and running

20:30 <karol2> @cjwfirmware pcie is not yet solved. Since this is a hard block the only thing that needs to be solved is the interconnect part

20:32 <owlhawk> kgugala: 2017.2 doesn't support most of the spartan7 parts. 2018.2 is the oldest version possible for the device I'm targeting.

20:32 <kgugala> @cjwfirmware solving pcie would require adding a fuzzer for finding pcie interconnection PIPs and their bits

20:33 <owlhawk> I'm aware of the issues with newer versions. Already had to fix some other things to get this far.

20:33 <kgugala> @owlhawk I see, you may try setting an option to lover the severity level of this message from critical to simple warning

20:33 <cjwfirmware> kgugala from what I understand ( and I could be wrong) , in Xilinx parts, the pcie is based on the high speed serdes and that is wrapped with standard logic. It may have the 8b10b encoder/decoder in hardware too. I don't know whats in lattice parts

20:34 <kgugala> this will prevent scripts from failing

20:34 <kgugala> not sure if it'd really work

20:36 <cjwfirmware> kgugala do you know of anyone looking into this right now?

20:39 <kgugala> cjwfirmware so the only thing needs solving is the transreceiver part

20:39 <kgugala> I don't think anybody is currently working on that

20:39 <owlhawk> kgugala: I'm guessing not, as placement also fails after the warnings, due to all the conflicts. I'll give it a shot though

20:42 <cjwfirmware> kgugala Thanks!

20:46 <kgugala> cjWfirmware there is a hard PCIE block in 7-series. The IP generator wraps it with additional logic and connects to GTRs

20:46 <kgugala> the core itself is descirbed here https://www.xilinx.com/support/documentation/ip_documentation/pcie_7x/v1_4/ug477_7Series_IntBlock_PCIe.pdf

20:48 <kgugala> so there are two things needs solving - pcie_2 block and GTRs

20:48 <kgugala> I mean their interconnects and configuration options

20:53 <cjwfirmware> kgugala Cool. Thanks. Just so I know the ontology of options, is it even an option in any of the currently supported lattice parts? (I'm less familiar with the lattice products)

20:54 <kgugala> I think @daveshah may know more about Lattice stuff

20:57 <daveshah> The SERDES transceivers are supported by Trellis/nextpnr

20:57 <daveshah> The high level way to config them (ie the meaning of the Verilog parameters) isn't fully known even though the mapping to bitstream is

20:58 <daveshah> There is no open source pcie ip yet either

20:58 <cjwfirmware> daveshah That is something I can potentially help with

20:59 <daveshah> https://github.com/whitequark/Yumewatari is a starting point but not complete

20:59 <tpb> Title: GitHub - whitequark/Yumewatari: 妖刀夢渡 (at github.com)

21:02 <cjwfirmware> daveshah Awesome. I'll look through it. Do you have any idea if it is possible on any of the currently supported lattice parts?

21:02 <daveshah> Yes, it's definitely possible

21:03 <daveshah> the nextpnr and Trellis side is complete

21:03 <daveshah> it's just no one has done the IP or found the optimum config

21:14 <cjwfirmware> daveshah Sweet. I'll see if I can find a manageable hardware set for development. PCIe analyzer + pci master and fpga slave that I can wire together.

21:22 <kgugala> @daveshah @cjwfirmware some work on ECP transreceivers is done here https://github.com/enjoy-digital/liteiclink it is used in USB 3.0 core https://github.com/enjoy-digital/usb3_pipe

21:22 <tpb> Title: GitHub - enjoy-digital/liteiclink: Small footprint and configurable Inter-Chip communication cores (at github.com)