05:01 <scanakci> thanks @_florent_ . I am currently trying to integrate the most recent version of BlackParrot to LiteX. I was stuck for some time. We finally noticed that the issue was because of a bug in verilator.

09:43 <pbinkowski> hi all

09:45 <pbinkowski> I'm working on enhancing liteeth to allow both SoftCPU and IP cores (Etherbone core etc.) access to the same MAC/PHY

09:47 <pbinkowski> I'd like to test my changes with the litex-buildenv firmware (it supports telnet so that should be a nice check) but I can't get the HW Ethernet cores working in litex-buildenv

09:50 <pbinkowski> I've modified my target to only instantiate the Etherbone core in a similar way to how it is done in mainline Litex Arty target

09:50 <pbinkowski> but I cant get it to respond to pings and ARP requests

09:51 <pbinkowski> all I get is a single ARP response just after loading the bitstream on the board and then it goes quiet

09:52 <pbinkowski> If someone wants to take a look, my code is located here https://github.com/antmicro/litex-buildenv/blob/hdmi2eth-hw-accel/targets/netv2/net.py#L64

09:52 <tpb> Title: litex-buildenv/net.py at hdmi2eth-hw-accel · antmicro/litex-buildenv · GitHub (at github.com)

09:54 <pbinkowski> I'm using the latest LiteEth/Litex-buildenv code

09:57 <pbinkowski> I've heard that issue similar to this already appeared in the past, so if anyone has any ideas what I can try to fix this now then please share

09:58 <pbinkowski> I think I will start with trying to bump the Litex submodule in buildenv as it is pretty far behind the current master

10:01 <pbinkowski> oh, and I forgot to mention that I've already tested the current mainline Litex and Etherbone core works fine there

10:19 <pbinkowski> looks like bumping litex did the trick :)

13:10 <_florent_> pbinkowski: sorry a bit late, but it's possible your issue was related to https://github.com/enjoy-digital/litex/commit/a26853702c109fb4e650ef2d53cfd631a4bec328

13:10 <tpb> Title: soc/interconnect/packet/Depacketizer: use both sink.valid and sink.re… · enjoy-digital/litex@a268537 · GitHub (at github.com)

13:18 <_florent_> otherwise that would indeed be an interesting feature, how are you planning to share the MAC/PHY between CPU and IP Core?

13:22 <pbinkowski> _florent_: my idea is to add a crossbar between LiteEthMACCore and LiteEthMACWishboneInterface/Packetizer&Depacketizer

13:22 <pbinkowski> that crossbar will send all incoming data to both CPU and IP

13:23 <pbinkowski> but it will arbitrate outgoing traffic between the IP and CPU

13:24 <pbinkowski> by monitoring stream valid and last signals

13:25 <pbinkowski> ie. when core has data valid then it will be granted access to output path until a data word with `last` flag is seen

13:29 <pbinkowski> but I think that my current code will still need some more work as I don't think that I'm handling data width, endianness and last_be vs last correctly

13:31 <pbinkowski> If you want to take a look then the WIP code is here https://github.com/antmicro/liteeth/blob/hw-sw-shared-phy/liteeth/mac/__init__.py

13:31 <tpb> Title: liteeth/__init__.py at hw-sw-shared-phy · antmicro/liteeth · GitHub (at github.com)

13:45 <_florent_> pbinkowski: with this architecture, the CPU will need to also read and discard packets that are going to the IP and it will not be able to do it as fast as the IP

13:47 <_florent_> when i was thinking about doing that, i was thinking having 2 separate MAC addresses for the CPU and the IP, share the MAC/PHY but add a crossbar on top of the LiteEthMACCore to redirect streams according to MAC addresses for RX and do the arbitration for TX.

13:51 <_florent_> this way, the CPU only receives its own packets and don't waste CPU cycles decoding packets that are for it and the IP can still use alsmost the full bandwidth

13:51 <_florent_> would that make senses for you application?

13:52 <pbinkowski> _florent_: I think that this will fit nicely as currently I'm already using different MAC addresses for CPU and IP

13:53 <pbinkowski> I will just need to figure out a filtering scheme as I see for example ARP requests use target MAC address of 00:00:00:00:00:00

13:53 <_florent_> pbinkowski: ok good, i'm going to have a closer look at your code. BTW this is something that should simulate nicely with litex_sim and ethernet support to speed up dev

13:56 <_florent_> pbinkowski: indeed, for ARP you can redirect the packet to both and only the one concerned will answer

14:00 <_florent_> ok so your solution seems very similar the one i was describing, it's just that there is no MAC filtering for the RX. But the MAC filtering could be an option that we enable or not, so you can probably continue with your solution and add MAC filtering later if that's really needed.

14:01 <pbinkowski> _florent_: ok, so I will try to get what I have currently to work and if I encounter any performance issues then I will add MAC filtering

14:01 <pbinkowski> thanks for help!

14:05 <_florent_> yes that sounds good. That will be a very useful feature to combine CPU flexibility and IP performance

22:54 <futarisIRCcloud> https://groupgets.com/campaigns/710-orangecrab

22:54 <tpb> Title: OrangeCrab | GroupGets (at groupgets.com)