| *** tpb has joined #symbiflow | 00:00 | |
| *** balmlake has joined #symbiflow | 00:08 | |
| *** wavedrom has joined #symbiflow | 00:12 | |
| mithro | Degi: _florent_ is in Europe, so generally up in about another 4-5 hours or about 8 hours ago | 00:35 |
|---|---|---|
| *** wallacejohn has joined #symbiflow | 00:36 | |
| Degi | Okay | 00:44 |
| * Degi is in europe too, RIP sleep | 00:44 | |
| *** balmlake has quit IRC | 00:46 | |
| *** epony has quit IRC | 01:03 | |
| *** epony has joined #symbiflow | 01:18 | |
| *** wallacejohn has quit IRC | 01:21 | |
| *** Bertl_oO is now known as Bertl_zZ | 01:55 | |
| *** citypw has joined #symbiflow | 02:04 | |
| *** Degi has quit IRC | 02:22 | |
| *** Degi has joined #symbiflow | 02:24 | |
| *** balmlake has joined #symbiflow | 02:57 | |
| *** balmlake has quit IRC | 03:14 | |
| *** HEGAZY has joined #symbiflow | 03:26 | |
| *** HEGAZY has quit IRC | 03:59 | |
| *** citypw has quit IRC | 06:30 | |
| _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:34 |
| *** citypw has joined #symbiflow | 06:36 | |
| _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:37 |
| _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. | 06:45 |
| *** Vonter has quit IRC | 08:17 | |
| *** Vonter has joined #symbiflow | 08:19 | |
| *** clay_1 has joined #symbiflow | 08:41 | |
| *** Vonter has quit IRC | 08:56 | |
| *** Vonter has joined #symbiflow | 08:57 | |
| *** clay_125 has joined #symbiflow | 09:07 | |
| *** clay_1 has quit IRC | 09:09 | |
| *** citypw has quit IRC | 09:16 | |
| *** citypw has joined #symbiflow | 09:19 | |
| *** hackerfoo has quit IRC | 10:04 | |
| *** hackerfoo has joined #symbiflow | 10:06 | |
| *** clay_125 has quit IRC | 10:37 | |
| *** clay_1 has joined #symbiflow | 10:40 | |
| clay_1 | Good morning Everyone ! | 10:40 |
| *** lambda has quit IRC | 10:42 | |
| *** lambda has joined #symbiflow | 10:44 | |
| 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:02 |
| Degi | Oh nice, pcie_analyzer already has a scrambler implemented | 11:04 |
| 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:46 |
| clay_1 | Can someone help me understand what are those files/ how are they generated ? | 11:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| clay_1 | so without them I will end up with wrong routing and wrong I/O ? | 11:55 |
| 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:56 |
| 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:57 |
| clay_1 | The problems come when I try to open the output | 11:58 |
| 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 ? | 11:59 |
| sf-slack | <acomodi> Sure | 12:02 |
| clay_1 | https://imgur.com/UR8EJDj | 12:03 |
| tpb | Title: Imgur: The magic of the Internet (at imgur.com) | 12:03 |
| 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:05 |
| clay_1 | Also, I omited using the .pcf file because it is creating a syntax error | 12:06 |
| clay_1 | what is that file doing ? giving real port names depending on the board or something ? | 12:07 |
| 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:08 |
| clay_1 | So its just for better naming, right ? | 12:10 |
| clay_1 | <<`top.route` can be generated only by using the whole VPR flow>> Can I run that independently of the make <test> ? | 12:14 |
| 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:17 |
| 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:21 |
| 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:22 |
| 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:24 |
| 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:28 |
| 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:29 |
| clay_1 | then I save the changes and click run implementation, which eventually reruns everything | 12:30 |
| clay_1 | and I end up with a design with extra luts | 12:31 |
| 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:32 |
| 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:33 |
| clay_1 | I will try no with pcf included to tell you the exact error it gives | 12:35 |
| 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:38 |
| 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:39 |
| sf-slack | <acomodi> The .v file is the one generated by fasm2bels? | 12:40 |
| clay_1 | yes | 12:41 |
| clay_1 | the original hdl that created the bitstream is vhdl, but that shouldnt matter, right ? | 12:41 |
| 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:43 |
| clay_1 | I dont remember that, probably I had used the vivado auto tool to assign the ios | 12:44 |
| *** Bertl_zZ is now known as Bertl | 12:45 | |
| clay_1 | the elbif generation, needs strictly verilog, right ? | 12:47 |
| clay_1 | Oh, also another thing, it doesnt matter which vivado version is used to generate the .bit, right ? | 12:48 |
| *** acomodi has joined #symbiflow | 12:50 | |
| *** OmniMancer has quit IRC | 13:02 | |
| *** proteus-guy has quit IRC | 13:15 | |
| -_whitenotifier-3- [yosys] kkumar23 opened issue #64: Branch : quicklogic : Dump report file for the area utilization - https://git.io/JvX5r | 13:54 | |
| *** clay_1 has quit IRC | 14:48 | |
| *** balmlake has joined #symbiflow | 15:08 | |
| *** _whitelogger has quit IRC | 15:12 | |
| *** _whitelogger has joined #symbiflow | 15:14 | |
| *** balmlake has quit IRC | 15:14 | |
| *** balmlake has joined #symbiflow | 15:47 | |
| *** balmlake has quit IRC | 15:51 | |
| *** az0re has quit IRC | 16:07 | |
| *** citypw has quit IRC | 16:15 | |
| *** az0re has joined #symbiflow | 16:51 | |
| *** Bertl is now known as Bertl_oO | 17:18 | |
| *** i8hantanu has joined #symbiflow | 17:40 | |
| *** i8hantanu has left #symbiflow | 17:52 | |
| *** clay_1 has joined #symbiflow | 17:57 | |
| *** clay_1 has quit IRC | 18:02 | |
| *** clay_1 has joined #symbiflow | 18:06 | |
| *** Wanderer_27 has joined #symbiflow | 18:22 | |
| *** Wanderer_27 has quit IRC | 18:43 | |
| *** Wanderer_27 has joined #symbiflow | 18:45 | |
| *** Wanderer_27 has quit IRC | 19:02 | |
| *** clay_1 has quit IRC | 19:39 | |
| *** OmniMancer has joined #symbiflow | 20:02 | |
| *** OmniMancer1 has joined #symbiflow | 20:03 | |
| *** OmniMancer has quit IRC | 20:06 | |
| *** acomodi has quit IRC | 20:10 | |
| 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:21 |
| Degi | Sorry wrong channel | 20:24 |
| *** wallacejohn has joined #symbiflow | 20:37 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!