15:02 <st-gourichon-fid> Hi! i have a strange condition where only on one specific machine, litex_simple would fail with: ModuleNotFoundError: No module named 'litex.boards'

15:02 <st-gourichon-fid> Several machines on Xubuntu 20.04, only this one fails. Even reinstalled the whole OS on a different partition.

15:05 <st-gourichon-fid> litex was installed using exactly the same procedure twice. The procedure installs all dependencies in a virtualenv and is repeatable.

15:06 <st-gourichon-fid> We also reinstalled "from scratch" (inside different directory tree, all components "git clone"d again, and a new python virtualenv) on the machine where things worked, and they still work.

15:06 <st-gourichon-fid> How to diagnose why one machine would "ModuleNotFoundError: No module named 'litex.boards'"?

15:08 <_florent_> st-gourichon-fid: litex.boards no longer exists (since no longer useful with the separate litex_boards repository)

15:08 <_florent_> st-gourichon-fid: it's possible I forgot to replace some imports. I'll double check

15:12 <_florent_> ah, litex_simple is no longer part of LiteX (was a target). I'll see if I revert it or if we just use the one from litex_boards

15:12 <_florent_> for now you can use: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/targets/simple.py

15:12 <st-gourichon-fid> _florent_ okay, thanks.

15:14 <st-gourichon-fid> Okay, I take it "shouldn't have worked anyway" (or similar), yet it works on other machines installed just the same. ¯\_(ツ)_/¯

15:19 <st-gourichon-fid> Thanks _florent_ . Now to check if litex is installed from command line I just do: python3 -m litex.soc.integration.soc_core

15:19 <st-gourichon-fid> This works on all machines.

15:20 <cr1901_modern> _florent_: I wanted to impl this as multiple PRs, but it became clear I should do it at once: https://github.com/enjoy-digital/litex/pull/772

15:20 <cr1901_modern> For now, litex_term should "just work" on Windows with these changes

15:20 <st-gourichon-fid> Notice: in a checked-out and populated (including submodules) installation of litex, this command yields 41 matches: fgrep litex.boards -rI

15:39 <st-gourichon-fid> Experienced again Yossy failure. YOSYS 0.9+3819 allocates LCs instead of RAM, LC consumption explodes, yosys fails. Fixed by using a commit known to work: git checkout aafaeb66dfd839b8223059884d2741dadc9e2d92

15:39 <st-gourichon-fid> s/Yossy/Yosys/

16:16 <_florent_> cr1901_modern: I saw your PR, thanks! I'm finishing something and will look at it

16:16 <roboknight> I was trying to find a definitive answer to the question of how to address the wishbone bus in python.  Are the upper bits of the bus at the lower end of a python array (i.e. would self.bus.adr[4:] exclude the higher bits) or are they at the upper end of a python array (i.e. self.bus.adr[0:28] exclude the higher bits?). I thought I found an answer

16:16 <roboknight> a while back, but I can't find the answer now.

16:17 <roboknight> And is the freenode.irclog down?

16:19 <_florent_> roboknight: self.bus.adr[:4] will take the 4 lower bits, self.bus.adr[4:] will take the uppers bits starting from bit 4.

16:19 <_florent_> (bit 0 = first bit)

16:20 <roboknight> Thanks.  That is what I thought, and I *KNOW* I saw an example somewhere, but I just couldn't find it again.

16:23 <roboknight> So, to be clear, if I said something like: self.bus.adr[:-4] ... this will NOT take the lower 4 bits (i.e. I want to ignore them)...

16:30 <_florent_> roboknight: to ignore the 4 lowers bits it's: self.bus.adr[4:]

16:32 <roboknight> Oh... so then if I wanted to ignore higher order bits it would be self.bus.adr[:4] ?  So self.bus.adr is treated as "little-endian"

16:32 <roboknight> ?

16:45 <_florent_> to ignore the 4 MSBs, it's self.bus.adr[:-4]