01:14 <Guest929> hi guys,

01:15 <Guest929> I am new to FPGA, i don't have single-chip-computer, windows system, only have tools like docker / multipass / qemu, is liteX a good choice to me?

01:16 <Guest929> I just need some guidance on how to set-up env and software simulator for users not having physical chips

01:21 <tpw_rules> depends what brand of FPGAs. the open source stuff is pretty straightforward to get going

11:54 <somlo> something's wrong with `litex-hub/pythondata-software-picolibc`: when I try to update (`git submodule update --recursive`) or clone from scratch (`git clone --recursive ...`) I get the following error: "fatal: remote error: upload-pack: not our ref 580d4f13de47a3eaf66f10cfc8537721b21dfc31; Errors during submodule fetch: pythondata_software_picolibc/data"

12:41 <shenchen> Is it possible to have Liteeth's HW and SW interface work at the same time? should HW and SW interface have different MAC address, and different IP?

12:44 <leons> Yes, that should be possible. LiteEth contains a built-in Xbar which allows this and provides you with a port in your HW design extracting / inserting traffic at your desired layer of abstraction (Ethernet / IP / UDP-Port)

12:45 <leons> Not entirely sure about whether LiteEth will then also use the ARP core for your HW stack, assuming you have a different IP and MAC. That should be relatively simple to hack in though.

12:47 <shenchen> when i tried this last night, i assign the same MAC and IP address to the LiteEthUDPIPCore and the software interface. Booting from the software interface (via tftp) stops working. When I remove the hardware UDPIP core, tftp booting works again.

12:49 <shenchen> i was pretty puzzled by this. now that i'm typing the question, i start to think that perhaps SW and HW interface should use different MAC address.

12:50 <leons> Which tap are you using to extract traffic into the fabric? If you’re matching on the MAC address in the Ethernet layer or IP address in the IP layer, then the software won’t see any traffic

12:50 <leons> If they should share MAC / MAC+IP, then you’d need a more intricate mechanism to detect which traffic should go where, or just divert UDP traffic to/from a specific port

12:52 <shenchen> hmm. let me check the C code that monitors the TAP

13:27 <leons> Ah, I was referring to a TAP in the sense of a hardware crossbar port.

15:34 <shenchen> leons, LiteEthMAC.__init__() has an argument `interface'. it seems that in order to have HW and SW interfaces at the same time, one should set interface='hybrid'

15:36 <shenchen> however, in soc.py LiteXSoc.add_ethernet(), ethmac is constructed with interface='wishbone'

16:17 <somlo> btw, failing to `git submodule update --recursive` in pythondata-software-picolibc isn't a dealbreaker -- I can still build against whatever was already in there; however, if I had to `git clone --recursive` and failed, I wouldn't be able to use the result to build the litex bios

16:17 <somlo> (I fortunately had a backup I could revert to)

16:18 <somlo> not sure who's in charge of pythondata-software-picolibc on litex-hub, maybe mithro?

16:19 <mithro> Hi?

16:20 <mithro> Can you log a bug?

16:31 <somlo> pythondata-software-picolibc itself doesn't have an "issues" tab, so where do you recommend I post it (litex?)

16:33 <somlo> or do you rather mean the upstream picolibc repo itself? (I'm doing a recursive clone right now to check if the bug shows up there as well)

16:34 <somlo> `git clone --recursive https://github.com/picolibc/picolibc` completes for me without any error, btw

16:34 <somlo> so not there :)

16:35 <tpw_rules> https://github.com/litex-hub/pythondata-software-picolibc/tree/master/pythondata_software_picolibc this submodule goes to a nonexistent commit

16:35 <tpw_rules> did picolibc have a force push?

16:36 <somlo> tpw_rules: if it *did* have a force push, shouldn't I be able to do a recursive clone *from scratch* without it erroring out (on the same nonexistent commit ID)?

16:37 <tpw_rules> no because you cloned the picolibc repo there

16:37 <tpw_rules> the pythondata-software-picolibc's submodule for picolibc points to a nonexistent commit

16:38 <tpw_rules> (and mysteriously the hash in the commit message does not match the hash of the submodule, so maybe this is a bot bug)

16:44 <somlo> oh, ok, that makes sense

20:50 <mithro> I also logged - https://github.com/litex-hub/pythondata-auto/issues/36

20:52 <mithro> Hrm, no kgugala here :-(

20:53 <tpw_rules> mithro: seems weird to me that the commit in the submodule and in the commit title do not match too?

20:54 <tpw_rules> unclear if that's the problem or just a symptom though

23:46 <Tari> Can somebody explain to me how you're meant to get a console for a simulated soc?

23:47 <Tari> if I run `litex_sim` it spins up a simulator which is clearly running because it's using a lot of CPU but I can't tell how to see any of the output I'd expect on the UART console

23:51 <Tari> I've kind of gleaned from assorted searching that one way to do this is to attach an etherbone bridge and go through `litex_server`

23:51 <Tari> but the documentation only seems to mention that you can run `litex_sim` and then says to attach a console to your board's serial port with no mention of the equivalent operation for simulation