00:18 <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 ?

05:33 <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:41 <shorne> ok, now its building, time to try out litescope

05:55 <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

07:29 <_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:31 <_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

08:09 <shivampotdar[m]> !nick shivampotdar

09:22 <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:23 <nats`> class Platform(XilinxPlatform):

09:23 <nats`> default_clk_name = "clk100"

09:23 <nats`> default_clk_period = 10

10:13 <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:55 <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> ).

11:07 <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:22 <_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:25 <_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:27 <_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:28 <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:31 <_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:32 <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:38 <_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:39 <_florent_> zyp: I'll try to have a look

11:41 <_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:42 <_florent_> gatecat: If your case is similar (avoid generating the LOC constraint) you can also probably do something similar

11:43 <gatecat> thanks, I'll look at that in a bit

12:50 <nats`> _florent_, yes I send it to you this evening but it's really a simple exemple

12:51 <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:52 <_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:55 <_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:57 <_florent_> zyp: I also added --with-etherbone args to ecpix5.py while testing

13:02 <pftbest> _florent_: thanks!

13:04 <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:06 <_florent_> zyp: thanks! I'll review and apply them

16:08 <somlo> anyone remember which of the two rj45 connectors on the ecp5-versa board is supposed to be connected to LiteETH?

16:35 <_florent_> somlo: It's the one near L5 and the USB connector

16:36 <_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:37 <somlo> _florent_: thanks! neither works for me right now, but I wanted to at least be barking up the right tree :D

16:39 <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:40 <_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:42 <somlo> _florent_: thanks, I'll restart the build to incorporate that commit

16:44 <_florent_> somlo: you should probably try with the smaller SoC first (just to be sure your cable is plugged correctly :))

16:45 <_florent_> it should build in less than 2 minutes

16:52 <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:53 <_florent_> hehe good idea

16:53 <somlo> now back to building the rocket SoC (which takes 30-45 minutes)

17:55 <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:56 <st-gourichon-fid> Appeared between 19fda3364ae1e2c96a77331fb19c4b8efd56d927 and current master 834c90b7 .

17:56 <st-gourichon-fid> So, appeared after 2021-01-08.

17:57 <st-gourichon-fid> Dunno if it's just a regression, or an actual problem in the design that wasn't spotted, though.

18:08 <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:38 <st-gourichon-fid> gatecat, thank you for your comment.

18:47 <st-gourichon-fid> Ah, indeed, ICESTORM_LC jumped from 94% to 100%. That looks quite significant!

18:48 <st-gourichon-fid> The same design jumping 6% from success to failure after a `git pull --ff-only` sounds fishy. :-/

19:22 <st-gourichon-fid> gatecat, the regression was introduced by commit ceb8a6502cc1315eb48fa654a073101c783013a3

19:24 <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:25 <st-gourichon-fid> Same design, changed litex version by one commit.

19:29 <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.

20:50 <_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 <_florent_> st-gourichon-fid: I'll disable it tomorrow