_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://freenode.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
HEGAZY has quit [Quit: Konversation terminated!]
HEGAZY has joined #litex
HEGAZY has quit [Quit: Konversation terminated!]
CarlFK has joined #litex
scanakci has quit [Quit: Connection closed for inactivity]
m4ssi has joined #litex
HEGAZY has joined #litex
HEGAZY has quit [Read error: Connection reset by peer]
HEGAZY has joined #litex
<Claude> tempting...
HEGAZY has quit [Read error: Connection reset by peer]
<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
<pbinkowski> all other packets are forwarded to both SoftCPU and IP cores
<pbinkowski> Simulation shows that this simple scheme works correctly and CPU is not bothered with packets meant for the HW accelerated part
<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
<tpb> Title: GitHub - antmicro/litex at hybrid-mac (at github.com)
<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
<pbinkowski> _florent_: btw. do you know of any more recent attempts at streaming video using HW accelerated LiteEth cores?
<tpb> Title: litex-buildenv/rtp.py at master · timvideos/litex-buildenv · GitHub (at github.com)
<_florent_> pbinkowski: nice! i'm not able to have a closer look at the code right now, but will do it very soon
<pbinkowski> but it seems fairly old
<_florent_> yes it seems old and just a proof of concept
<_florent_> IIRC think Greg did something some video streaming with LiteETH, i'll try to find that
<_florent_> i think he used the tty frontend as a basis
<pbinkowski> great! If you find something then let me know
<tpb> Title: ButterStick/gateware/GigE at master · gregdavill/ButterStick · GitHub (at github.com)
CarlFK has quit [Ping timeout: 268 seconds]
m4ssi has quit [Remote host closed the connection]
<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)
<tpb> Title: litesdcard/phy.py at master · enjoy-digital/litesdcard · GitHub (at github.com)
<somlo> but clkfb isn't a subsignal in any of the platforms I could find, neither in litex nor in litex-boards
<somlo> any memory of why that ended up being tested for, originally?
CarlFK has joined #litex
<_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.
<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 )
<daveshah> There isn't actually an ECP5 equivalent really
<daveshah> Just use a regular input and hope it becomes a global buffer
<_florent_> somlo: it's only used on very specific designs, you can avoid implementing this part for ECP5.
<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?
<daveshah> Yeah
<somlo> daveshah, thanks!
<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
<_florent_> you can keep the if hasattr(pads, "clkfb") parts, but just raise NotImplementedError in it :)
<somlo> ok, I should have come up with that on my own, but for some sad reason didn't :D
<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?
<daveshah> I think so, but it's been a while since I looked at DDR stuff
somlo has quit [Ping timeout: 258 seconds]
somlo has joined #litex
HEGAZY has joined #litex
m4ssi has joined #litex
m4ssi has quit [Remote host closed the connection]
HEGAZY has quit [Quit: Konversation terminated!]
HEGAZY has joined #litex
m4ssi has joined #litex
m4ssi has quit [Remote host closed the connection]
<somlo> daveshah: I think I figured it out eventually: https://pastebin.com/QMx05axZ
<tpb> Title: [Python] # Cmd input DDR self.specials += Instance("IDDR", - Pastebin.com (at pastebin.com)
<daveshah> I think that's correct
<somlo> on xilinx, Q2 is the data at the negative clock edge, so I want Q1 on ecp5
<somlo> ok, thanks for confirming
<daveshah> I also seem to remember that ECP5 is effectively always in SAME_EDGE_PIPELINED mode
<somlo> I think in the case of litesdcard the [_pipelined] part doesn't matter, as we're discarding xilinx Q1 (which is ecp5 Q0)
<somlo> it's the same_edge portion that's important
<daveshah> Yep
<somlo> ok, I think the phy part has a chance now, now I gotta come up with a "SDClockerECP5"...
<awygle> litesdcard supports more than just the SPI mode, right?
<_florent_> awygle: it's only supporting 4-bit SD mode
<awygle> i see
<awygle> are you at all concerned about the sd association licensing?
<_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
scanakci has joined #litex
HEGAZY has quit [Quit: Konversation terminated!]