00:35 <mithro> Degi: _florent_ is in Europe, so generally up in about another 4-5 hours or about 8 hours ago

00:44 <Degi> Okay

06:34 <_florent_> Degi: you can find here some simple designs with transceivers: https://github.com/enjoy-digital/liteiclink/tree/master/examples/transceiver, just transmitting a counter to TX and connecting it to leds on RX. It also integrates a PRBS that can be used to evaluate the link in loopback or between boards.

06:37 <_florent_> PCIe and USB3 are pretty similar in the lower layers, so you can probably find some inspiration in https://github.com/enjoy-digital/usb3_pipe as mithro said.

06:37 <tpb> Title: GitHub - enjoy-digital/usb3_pipe: USB3 PIPE interface for Xilinx 7-Series / Lattice ECP5 (at github.com)

06:45 <_florent_> To work on a PCIe PHY/Core, i would really recommend starting at PCIe Gen1 2.5Gbps X1 and having a way to capture the raw data and analyze it. This equipment can be quite expensive (>10k$ generally), Franck Jullien has been working on interposer/capture boards and we are trying to creating a SoC to capture data here: https://github.com/enjoy-digital/pcie_analyzer. This should reduce a lot the costs, probably less

06:45 <_florent_> than 500$ with interposer/capture + FPGA board and even less if you already have an FPGA board with PCIe/DDR3/4 and Ethernet.

10:40 <clay_1> Good morning Everyone !

11:02 <Degi> Hm couldn't you use a second ECP5 to capture the raw transmitted data?

11:02 <Degi> Unless you want to measure waveforms...

11:04 <Degi> Oh nice, pcie_analyzer already has a scrambler implemented

11:46 <clay_1> The results I am getting are not good and I suspect and hope it is because I dont add arguements for the following files `top.route` and `top.eblif`

11:49 <clay_1> Can someone help me understand what are those files/ how are they generated ?

11:51 <sf-slack> <acomodi> clay_1: those files are generated during the whole flow. More specifically, `top.route` is the routing generated with VPR, while `top.eblif` is the netlist generated by the Yosys synthesys flow

11:52 <clay_1> does any of those require inputs from anything other than the bitstream and files you can derive from it (e.g fasm)

11:52 <clay_1> ?

11:53 <sf-slack> <acomodi> They are not strictly necessary to complete the fasm2bels build, but they make the whole build more robust. `top.eblif` should be used to correctly set the IOs of the design, while `top.route` is used to correctly produce routing constraints in the resulting `top_bit.v.tcl` file

11:55 <clay_1> so without them I will end up with wrong routing and wrong I/O ?

11:56 <sf-slack> <acomodi> `top.route` can be generated only by using the whole VPR flow. `top.eblif` can be generated using `make <test>_eblif`

11:56 <sf-slack> <acomodi> without top.route you will have an unconstrained routing

11:56 <sf-slack> <acomodi> without top.eblif you will have different IO names w.r.t. the original design

11:57 <sf-slack> <acomodi> what errors do you get exactly?

11:57 <clay_1> Oh so if it is just names for IOs I dont care as long as they are the same as the ones in the bitstream

11:57 <clay_1> When running the fasm2bels I get no errors

11:58 <clay_1> The problems come when I try to open the output

11:59 <clay_1> For example, the design in the bitstream is using only one lut

11:59 <clay_1> the output verilog has more luts that are set to zero

11:59 <clay_1> Am I allowed to upload a picture here ?

12:02 <sf-slack> <acomodi> Sure

12:03 <clay_1> https://imgur.com/UR8EJDj

12:03 <tpb> Title: Imgur: The magic of the Internet (at imgur.com)

12:05 <clay_1> So when implementing at some point the tcl comands generated give an error which end ups with only the ff beeing set in the correct spot

12:06 <clay_1> Also, I omited using the .pcf file because it is creating a syntax error

12:07 <clay_1> what is that file doing ? giving real port names depending on the board or something ?

12:08 <sf-slack> <acomodi> It is a constraint file that is used to map the IOs of the device to the top level IO signals

12:10 <clay_1> So its just for better naming, right ?

12:14 <clay_1> <<`top.route` can be generated only by using the whole VPR flow>> Can I run that independently of the make <test> ?

12:17 <sf-slack> <acomodi> It is possible, but the best way is to create a new test with your initial HDL and run through the whole flow. If you want to generate top.route manually, you would need to go through all the steps to get there (which are performed by the whole build system already)

12:21 <clay_1> Giving the HDL code would beat my purpose though

12:21 <clay_1> Isnt all the information about bels and pips used in the .fasm file ?

12:22 <clay_1> If thats the case, shouldnt it be enough for marking everything used in the bitstream on vivado view ?

12:22 <clay_1> (thats basically what I am after)

12:24 <sf-slack> <acomodi> Ok, so, what errors do you get when you try to implement with Vivado the generated top_bit.v and top_bit.v.tcl?

12:28 <clay_1> Verilog file loads fine, synthesis copmpletes (the rtl design has that wierd extra luts in the pic I uploaded before)

12:28 <clay_1> then I open the synthesized design and I source the tcl

12:29 <clay_1> and there I get the following warning, but no error

12:29 <clay_1> `# set_property LOC [get_sites IOB_X0Y28] $cellWARNING: [Vivado 12-180] No cells matched '*LIOB33_X0Y111_IOB_X0Y111_IBUF'.# set cell [get_cells *LIOB33_X0Y111_IOB_X0Y111_IBUF]# if { $cell == {} } {# error "Failed to find cell!"# }Failed to find cell! while executing"error "Failed to find cell!"" invoked from within"if { $cell == {} } {

12:29 <clay_1> error "Failed to find cell!"}"`

12:30 <clay_1> then I save the changes and click run implementation, which eventually reruns everything

12:31 <clay_1> and I end up with a design with extra luts

12:32 <clay_1> a flipflop correctly placed

12:32 <clay_1> and teh valid lut incorectly placed ( and also unfixed) only the ff is fixed

12:33 <sf-slack> <acomodi> Ok, I am pretty sure that is because of the wrong names given to the IOs. Given that the pcf is absent, a default name is assigned to the IOs, and probably, during synthesys they get optimized as they are connected to nothing. You can verify that in the top_bit.v.

12:35 <clay_1> I will try no with pcf included to tell you the exact error it gives

12:38 <clay_1> In the .v file It has the following ` input [7:0] led, input rx, input tx, output [8:0] led );`

12:38 <clay_1> and the error is `port led is already defined `

12:39 <sf-slack> <acomodi> Well, this led is both an input and an output as far as I can see. Is that intended?

12:39 <clay_1> no, and I could just change one of the names, right ?

12:40 <sf-slack> <acomodi> The .v file is the one generated by fasm2bels?

12:41 <clay_1> yes

12:41 <clay_1> the original hdl that created the bitstream is vhdl, but that shouldnt matter, right ?

12:43 <sf-slack> <acomodi> Hmm, it shouldn't matter, but it would be best to obtain an eblif from that and feed it in fasm2bels as well. And the original hdl has the led set as inout?

12:44 <clay_1> I dont remember that, probably I had used the vivado auto tool to assign the ios

12:47 <clay_1> the elbif generation, needs strictly verilog, right ?

12:48 <clay_1> Oh, also another thing, it doesnt matter which vivado version is used to generate the .bit, right ?

13:54 <_whitenotifier-3> [yosys] kkumar23 opened issue #64: Branch : quicklogic : Dump report file for the area utilization - https://git.io/JvX5r

20:21 <Degi> Does it make sense to lump impedance discontinuities together?

20:21 <Degi> Like if a transmission line is terminated on both sides and has one discontinuity, then that shouldn't cause refletions in the output, right?

20:24 <Degi> Sorry wrong channel