11:40 <Claude> tempting...

14:57 <pbinkowski> _florent_: I have an initial version of the crossbar working, it already supports basic MAC filtering - if RX packet destination MAC is the one assigned to IP cores then it is not forwarded to SoftCPU

14:57 <pbinkowski> all other packets are forwarded to both SoftCPU and IP cores

14:58 <pbinkowski> Simulation shows that this simple scheme works correctly and CPU is not bothered with packets meant for the HW accelerated part

14:59 <pbinkowski> If you want to take a look then the code is here https://github.com/antmicro/litex/tree/hybrid-mac and here https://github.com/antmicro/liteeth/tree/hw-sw-shared-phy

14:59 <tpb> Title: GitHub - antmicro/litex at hybrid-mac (at github.com)

15:00 <pbinkowski> and this also works on NeTV2 in litex-buildenv ie. I can ping the Etherbone core while being connected to HDMI2USB firmware telnet console

15:02 <pbinkowski> _florent_: btw. do you know of any more recent attempts at streaming video using HW accelerated LiteEth cores?

15:03 <pbinkowski> because I saw this https://github.com/timvideos/litex-buildenv/blob/master/gateware/streamer/rtp.py

15:03 <tpb> Title: litex-buildenv/rtp.py at master · timvideos/litex-buildenv · GitHub (at github.com)

15:03 <_florent_> pbinkowski: nice! i'm not able to have a closer look at the code right now, but will do it very soon

15:03 <pbinkowski> but it seems fairly old

15:04 <_florent_> yes it seems old and just a proof of concept

15:05 <_florent_> IIRC think Greg did something some video streaming with LiteETH, i'll try to find that

15:05 <_florent_> i think he used the tty frontend as a basis

15:07 <pbinkowski> great! If you find something then let me know

15:08 <_florent_> https://github.com/gregdavill/ButterStick/tree/master/gateware/GigE

15:08 <tpb> Title: ButterStick/gateware/GigE at master · gregdavill/ButterStick · GitHub (at github.com)

18:32 <somlo> _florent_: in litesdcard/phy.py, there's several places testing 'if hasattr(pads, "clkfb"): ...' (e.g., https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/phy.py#L573 but there's a bunch more)

18:32 <tpb> Title: litesdcard/phy.py at master · enjoy-digital/litesdcard · GitHub (at github.com)

18:33 <somlo> but clkfb isn't a subsignal in any of the platforms I could find, neither in litex nor in litex-boards

18:33 <somlo> any memory of why that ended up being tested for, originally?

18:39 <_florent_> somlo: indeed, it's not used in the examples, but i was using it on others designs. It's used on designs with a high clock freq and with 3.3v <--> 1.8V level translator between the FPGA and the SDCard. The chip is generating a clock feedback (which is a phase shift version of the one sent by the FPGA) that ease the sampling of returned data in the FPGA.

18:41 <somlo> _florent_: ok, thanks! (Reason I asked is that it's instantiating an "IBUFG" on Xilinx, and I was hoping I won't have to figure out the ecp5 equivalent to preserve compatibility :D )

18:42 <daveshah> There isn't actually an ECP5 equivalent really

18:42 <daveshah> Just use a regular input and hope it becomes a global buffer

18:42 <_florent_> somlo: it's only used on very specific designs, you can avoid implementing this part for ECP5.

18:43 <somlo> so if an "i" is connected to an "o" via an "IBUFG", just assign them on ecp5 instead and hopefully we'll be OK?

18:43 <daveshah> Yeah

18:43 <somlo> daveshah, thanks!

18:45 <somlo> _florent_: there's also 'if not hasattr(pads, "clkfb"): ...' elsewhere, so in the absence of better clue and for defensive coding I don't want to presume there will *never* be a 'clkfb' pad :) But I'm just beginning to get my bearings, so maybe with more clue later down the road I'll be a bit less defensive :D

18:46 <_florent_> you can keep the if hasattr(pads, "clkfb") parts, but just raise NotImplementedError in it :)

18:50 <somlo> ok, I should have come up with that on my own, but for some sad reason didn't :D

19:24 <somlo> daveshah: when porting from Xilinx IDDR to ecp5 IDDRX1F, if the former has DDR_CLK_EDGE="SAME_EDGE_PIPELINED", I'm assuming that means I want IDDRX1F output Q0 (data at positive edge of clock), and *not* Q1 (data at negative clock edge), which would match DDR_CLK_EDGE="OPPOSITE_EDGE" -- am I making sense?

19:39 <daveshah> I think so, but it's been a while since I looked at DDR stuff

20:42 <somlo> daveshah: I think I figured it out eventually: https://pastebin.com/QMx05axZ

20:42 <tpb> Title: [Python] # Cmd input DDR self.specials += Instance("IDDR", - Pastebin.com (at pastebin.com)

20:43 <daveshah> I think that's correct

20:43 <somlo> on xilinx, Q2 is the data at the negative clock edge, so I want Q1 on ecp5

20:43 <somlo> ok, thanks for confirming

20:44 <daveshah> I also seem to remember that ECP5 is effectively always in SAME_EDGE_PIPELINED mode

20:45 <somlo> I think in the case of litesdcard the [_pipelined] part doesn't matter, as we're discarding xilinx Q1 (which is ecp5 Q0)

20:46 <somlo> it's the same_edge portion that's important

20:46 <daveshah> Yep

20:48 <somlo> ok, I think the phy part has a chance now, now I gotta come up with a "SDClockerECP5"...

21:13 <awygle> litesdcard supports more than just the SPI mode, right?

21:21 <_florent_> awygle: it's only supporting 4-bit SD mode

21:22 <awygle> i see

21:22 <awygle> are you at all concerned about the sd association licensing?

21:32 <_florent_> not really for now, this is just a small project to interface a SoC with SD cards and have better speeds than using SPI mode