| *** tpb has joined #litex | 00:00 | |
| nats` | maybe a silly question but when I declare the clock period in the platform I don't see it in the generated ucf/xdc | 00:18 |
|---|---|---|
| nats` | is it normal ? | 00:18 |
| *** lf has quit IRC | 00:55 | |
| *** lf_ has joined #litex | 00:55 | |
| *** lkcl has quit IRC | 02:25 | |
| *** Bertl is now known as Bertl_zZ | 02:38 | |
| *** lkcl has joined #litex | 02:38 | |
| *** Degi_ has joined #litex | 03:07 | |
| *** Degi has quit IRC | 03:07 | |
| *** Degi_ is now known as Degi | 03:07 | |
| *** felix__ is now known as felix_ | 03:34 | |
| *** _whitelogger has quit IRC | 03:42 | |
| *** _whitelogger has joined #litex | 03:44 | |
| *** futarisIRCcloud has joined #litex | 04:50 | |
| *** FFY00_ has quit IRC | 04:54 | |
| *** FFY00_ has joined #litex | 05:00 | |
| *** shorne_ is now known as shorne | 05:32 | |
| shorne | well, jtagbone is working, but having an issue getting litescope to route, my design needs 101 RAM cells, but the device as 100 | 05:33 |
| shorne | changing the litescope sample depth doesnt seem to help | 05:33 |
| shorne | Ill try to turn off some features in the CPU code | 05:33 |
| shorne | ok, now its building, time to try out litescope | 05:41 |
| shorne | it works, I had to move my csr.csv file and analyser.csv file into the right place but then it works, I got a blank trace on the sdcard, but thats expected | 05:55 |
| *** kgugala has quit IRC | 06:11 | |
| *** kgugala has joined #litex | 06:11 | |
| *** kgugala_ has joined #litex | 06:13 | |
| *** kgugala has quit IRC | 06:16 | |
| *** rozpruwacz has joined #litex | 06:20 | |
| *** rozpruwacz has quit IRC | 06:46 | |
| *** rozpruwacz has joined #litex | 06:46 | |
| *** TMM has quit IRC | 07:09 | |
| *** TMM has joined #litex | 07:09 | |
| _florent_ | nats`: Are you using Plaform.add_period_constraint? If you execute an Artix7 target, ex arty.py, you'll see the constraint on the 100MHz input in the generated .xdc | 07:29 |
| _florent_ | shorne: Good you got jtagbone working, LiteScope will indeed use some blockrams, so this can be tricky on a design that is already already almost full | 07:31 |
| *** RaYmAn has quit IRC | 07:35 | |
| *** RaYmAn has joined #litex | 07:48 | |
| *** shivampotdar[m] has joined #litex | 08:08 | |
| shivampotdar[m] | !nick shivampotdar | 08:09 |
| *** shivampotdar[m] is now known as shivampotdar | 08:10 | |
| *** shivampotdar has joined #litex | 08:11 | |
| *** futarisIRCcloud has quit IRC | 08:59 | |
| nats` | _florent_, I tried with a spartan 6 target for an easier test with led | 09:22 |
| nats` | I used a default(clock name / period) | 09:22 |
| nats` | class Platform(XilinxPlatform): | 09:23 |
| nats` | default_clk_name = "clk100" | 09:23 |
| nats` | default_clk_period = 10 | 09:23 |
| *** FFY00_ has quit IRC | 10:06 | |
| *** FFY00_ has joined #litex | 10:07 | |
| *** Bertl_zZ is now known as Bertl | 10:11 | |
| zyp | _florent_, is there a canonical endianness for wide buses in liteeth? mismatching endiannesses is the sort of problem where two wrongs make a right, and I'd rather get it all consistent :) | 10:13 |
| *** pftbest has quit IRC | 10:29 | |
| *** pftbest has joined #litex | 10:33 | |
| rozpruwacz | Hi All. If anyone is interesting in reviewing my work related to litespi and litegpio linux kernel drivers I will be happy to get some reviews. I pushed my implementation of gpio interrupts handling in linux driver here https://github.com/mczerski/linux/tree/litex-riscv, there are my two commits. 444d3dae2e78f8e89ed9c1788f30d2cf574aebe3 is about the gpio interrupts and 8d885998822bb625aa854b52e6627ab42f03bfb9 is about litespi chip select | 10:55 |
| rozpruwacz | signal handling. Regarding spi chip select I encountered an issue that my spi slave required multibyte transfers without deasserting cs signal. There is set_cs callback for spi_master which allows the higher level api to handle cs signal. This was required for my slave device to work. This chip select handling also require changes in HDL which I pushed here https://github.com/mczerski/litex (commit c234d1b54ce73950614e270b26e29b5e84f4c7cf | 10:55 |
| rozpruwacz | ). | 10:55 |
| gatecat | _florent_: is there a way of creating unconstrained IO pins in LiteX (I need to work around a slightly icky Radiant bug around the hard MIPI IP core, where the MIPI pads can't have constraints on them or Radiant fails) ? | 11:07 |
| *** FFY00_ has quit IRC | 11:19 | |
| *** FFY00_ has joined #litex | 11:20 | |
| _florent_ | nats`: I just tried doing something similar on the minispartan6 (using the default CRG) and I still see the clock constraint in the .ucf | 11:22 |
| _florent_ | If you have a minimal repro, can you share it? | 11:22 |
| _florent_ | zyp: Etherbone with dw=32 was working previously is even the default IIRC, so I'm still not sure the issue on ECPIX5 is related to the core itself but could also be some malformed RX packets. I would need to do more tests on different boards | 11:25 |
| _florent_ | gatecat: At some point it was possible with Pins("X") but I have to disable this since was causing an issue on a design I was working on recently. But we could add back a way to define pins without generating the constraints. | 11:27 |
| gatecat | OK, thanks, I think I'm just gonna ignore Radiant and try and get nextpnr working for now anyway (and manually patch the constraints if I need to try Radiant...) but if you have a moment then that would be useful | 11:28 |
| _florent_ | For a quick test, you can probably revert this: https://github.com/enjoy-digital/litex/commit/8623536a8a95053bf75e1ad5191a278b2fd18df4 | 11:31 |
| _florent_ | and use Pins("X") (or Pins("X X ...") if a multi-bit signal) | 11:31 |
| gatecat | oh even easier, thanks! | 11:32 |
| zyp | _florent_, did you see the screenshots I posted last night? arp/icmp not working was clearly an endianness issue, solved by flipping the endianness | 11:32 |
| _florent_ | zyp: yes, but I'm still not sure it's really a endianness issue (since dw=32 works in simulation and other boards), this could also be an issue with the start of the RX frame that would cause issues very similar to endianness issues | 11:38 |
| _florent_ | zyp: I'll try to have a look | 11:39 |
| _florent_ | gatecat: In fact the case I reverted this (integrating LiteDRAM on Gowin) the tools were requiring the IOStandard constraints but not the LOC constraints, so did the revert I just shared and then added this to the Gowin backend: | 11:41 |
| _florent_ | https://github.com/enjoy-digital/litex/commit/f324f9531af311853d83eb4700af0e08e440e75f | 11:41 |
| _florent_ | gatecat: If your case is similar (avoid generating the LOC constraint) you can also probably do something similar | 11:42 |
| gatecat | thanks, I'll look at that in a bit | 11:43 |
| *** FFY00_ has quit IRC | 11:46 | |
| *** FFY00_ has joined #litex | 11:47 | |
| *** Melkhior has quit IRC | 11:50 | |
| *** lkcl has quit IRC | 11:56 | |
| *** lkcl_ has joined #litex | 12:09 | |
| nats` | _florent_, yes I send it to you this evening but it's really a simple exemple | 12:50 |
| nats` | I must miss something silly :) | 12:51 |
| _florent_ | zyp: This was a stupid issue, the UDPIPCore was not running in the right clock domain: https://github.com/enjoy-digital/litex/commit/5af8e5c9345053763f6d89764790a7fc8793b8bf | 12:51 |
| _florent_ | zyp: With this, the data-width is kept to 8 up to the UDP Layer (with a 125MHz clock) and Etherbone is then running at lower speed (sys_clk) | 12:52 |
| _florent_ | zyp: Running the core with a data-width != 8 is another thing, I have a version working that has been validated at 1Gbps with a 32-bit data-width on EC5 and 10Gbps with a 64-bit data-width (on Kintex7) but I still need to spend time integrating the changes correctly. | 12:55 |
| zyp | ah, makes sense | 12:55 |
| _florent_ | zyp: I also added --with-etherbone args to ecpix5.py while testing | 12:57 |
| pftbest | _florent_: thanks! | 13:02 |
| zyp | as long as the udp layer meets timing at 125MHz easily I'm happy enough with that solution for now | 13:04 |
| zyp | here's a few minor unrelated things I ran across: https://paste.jvnv.net/view/yNFqA | 13:04 |
| tpb | Title: JVnV Pastebin View paste – Untitled (at paste.jvnv.net) | 13:04 |
| _florent_ | zyp: sorry for the time you spent on that, I thought the core was already running in the eth clock domain. For info I found the issue by capturing the ethphy.source with LiteScope and saw some backpressure on the ready signal (that is not supposed to happen). | 13:04 |
| _florent_ | zyp: thanks! I'll review and apply them | 13:06 |
| *** lkcl_ has quit IRC | 13:33 | |
| *** pftbest has quit IRC | 13:45 | |
| *** pftbest has joined #litex | 13:45 | |
| *** lkcl_ has joined #litex | 13:47 | |
| *** pftbest has quit IRC | 13:49 | |
| *** Bertl is now known as Bertl_oO | 13:53 | |
| *** pftbest has joined #litex | 13:57 | |
| *** Melkhior has joined #litex | 14:56 | |
| *** rj has joined #litex | 15:28 | |
| *** rj has quit IRC | 15:53 | |
| *** rj has joined #litex | 15:55 | |
| somlo | anyone remember which of the two rj45 connectors on the ecp5-versa board is supposed to be connected to LiteETH? | 16:08 |
| _florent_ | somlo: It's the one near L5 and the USB connector | 16:35 |
| _florent_ | somlo: But due to a bug fix in the ecp5rgmii (delay were not applied correctly) it's possible the delays need to be specified in the target | 16:36 |
| _florent_ | I'm testing this | 16:36 |
| somlo | _florent_: thanks! neither works for me right now, but I wanted to at least be barking up the right tree :D | 16:37 |
| *** rj has quit IRC | 16:38 | |
| somlo | for context, I've just built the latest versions of yosys/trellis/nextpnr, which seem to fit a linux-capable rocket/litex with ethernet much more reliably with 99% slice utilization into the 45k ecp5 | 16:39 |
| _florent_ | somlo: https://github.com/litex-hub/litex-boards/commit/8fb80053f716cd8b752064de2249639cde3a5c1b | 16:40 |
| _florent_ | tested with ./versa_ecp5.py --with-etherbone --cpu-type=None --integrated-main-ram-size=0x1000 --build --load to speed up P&R | 16:40 |
| somlo | the previous toolchain iteration bounced back and forth over the 100% utilization limit, but now it seems p&r is significantly tighter (thanks gatecat, as always :) | 16:40 |
| somlo | _florent_: thanks, I'll restart the build to incorporate that commit | 16:42 |
| *** rj has joined #litex | 16:42 | |
| _florent_ | somlo: you should probably try with the smaller SoC first (just to be sure your cable is plugged correctly :)) | 16:44 |
| *** rj has quit IRC | 16:45 | |
| _florent_ | it should build in less than 2 minutes | 16:45 |
| *** rj has joined #litex | 16:45 | |
| somlo | _florent_: amazing! and yeah, it pings, so the rj45 closer to the middle of the board (and to the usb connector) is indeed phy0 :) | 16:52 |
| * somlo reaches for the permanent marker :) | 16:52 | |
| _florent_ | hehe good idea | 16:53 |
| somlo | now back to building the rocket SoC (which takes 30-45 minutes) | 16:53 |
| *** Bertl_oO is now known as Bertl | 16:56 | |
| *** rozpruwacz has quit IRC | 17:07 | |
| *** kgugala_ has quit IRC | 17:08 | |
| *** kgugala has joined #litex | 17:08 | |
| *** rj has quit IRC | 17:20 | |
| *** lkcl_ has quit IRC | 17:22 | |
| *** rj has joined #litex | 17:24 | |
| *** lkcl_ has joined #litex | 17:35 | |
| st-gourichon-fid | Something that looks like a regression. New error message "ERROR: Failed to expand region (0, 0) |_> (25, 31) of 5294 ICESTORM_LCs" on a design that used to compile. | 17:55 |
| st-gourichon-fid | Appeared between 19fda3364ae1e2c96a77331fb19c4b8efd56d927 and current master 834c90b7 . | 17:56 |
| st-gourichon-fid | So, appeared after 2021-01-08. | 17:56 |
| st-gourichon-fid | Dunno if it's just a regression, or an actual problem in the design that wasn't spotted, though. | 17:57 |
| *** rj has quit IRC | 18:05 | |
| gatecat | It sounds like the design is just a bit too large | 18:08 |
| gatecat | Chances are it was always on the marginal side and something has pushed it over the edge | 18:08 |
| *** rj has joined #litex | 18:09 | |
| *** rj has quit IRC | 18:16 | |
| *** rozpruwacz has joined #litex | 18:31 | |
| st-gourichon-fid | gatecat, thank you for your comment. | 18:38 |
| st-gourichon-fid | Ah, indeed, ICESTORM_LC jumped from 94% to 100%. That looks quite significant! | 18:47 |
| st-gourichon-fid | The same design jumping 6% from success to failure after a `git pull --ff-only` sounds fishy. :-/ | 18:48 |
| *** rozpruwacz has quit IRC | 18:51 | |
| *** rozpruwacz has joined #litex | 18:54 | |
| *** rj has joined #litex | 19:01 | |
| *** rozpruwacz has quit IRC | 19:07 | |
| *** lkcl_ has quit IRC | 19:08 | |
| *** lkcl_ has joined #litex | 19:21 | |
| st-gourichon-fid | gatecat, the regression was introduced by commit ceb8a6502cc1315eb48fa654a073101c783013a3 | 19:22 |
| st-gourichon-fid | https://github.com/enjoy-digital/litex/commit/ceb8a6502cc1315eb48fa654a073101c783013a3 | 19:24 |
| st-gourichon-fid | 2020.12-165-g6e883b45.log:Info: ICESTORM_LC: 4771/ 5280 90% | 19:24 |
| st-gourichon-fid | 2020.12-166-gceb8a650.log:Info: ICESTORM_LC: 5294/ 5280 100% | 19:24 |
| *** rozpruwacz has joined #litex | 19:24 | |
| st-gourichon-fid | Same design, changed litex version by one commit. | 19:25 |
| st-gourichon-fid | Looks like it adds an optional parameter to the vexriscv constructor, to enable or disable a timer, but puts it enabled by default. | 19:29 |
| *** rj has quit IRC | 19:33 | |
| *** rj has joined #litex | 19:35 | |
| *** lkcl_ has quit IRC | 19:48 | |
| *** lkcl_ has joined #litex | 20:01 | |
| *** rozpruwacz has quit IRC | 20:04 | |
| *** rj has quit IRC | 20:15 | |
| *** rozpruwacz has joined #litex | 20:16 | |
| *** rj has joined #litex | 20:19 | |
| *** rozpruwacz has quit IRC | 20:44 | |
| _florent_ | st-gourichon-fid: yes that's indeed probably related to the timer, I saw this while merging but was not sure how much it would increase resource usage | 20:50 |
| *** rozpruwacz has joined #litex | 20:50 | |
| _florent_ | st-gourichon-fid: I'll disable it tomorrow | 20:50 |
| *** rj has quit IRC | 21:00 | |
| *** rj has joined #litex | 21:03 | |
| *** TMM has quit IRC | 21:15 | |
| *** TMM has joined #litex | 21:15 | |
| *** rj has quit IRC | 21:45 | |
| *** rj has joined #litex | 21:49 | |
| *** Melkhior has quit IRC | 22:28 | |
| *** rj has quit IRC | 22:29 | |
| *** rj has joined #litex | 22:31 | |
| *** rj has quit IRC | 23:26 | |
| *** rj has joined #litex | 23:30 | |
| *** rj has quit IRC | 23:54 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!