02:24 <somlo> _florent_: I get these values (in CSRBank init): paging: 2048; paging//4: 512; bus.alignment: 64; aligned_paging:256

02:25 <somlo> so aligned_paging is half what it should have been if bus.alignment is 64 and not 32 :)

08:14 <_florent_> somlo: sorry for that, this is fixed, aligned_paging was indeed not computed correctly

08:15 <_florent_> somlo: i will probably run some configurations with litex_sim in Travis-CI to catch this more easily

11:41 <somlo> _florent_: thanks, I'll give it another spin when I get into the office in an hour or so :)

11:42 <_florent_> somlo: ok, FYI i reproduced your issue with litex_sim --cpu-type=rocket

14:45 <acathla> what's the difference between litex/litex/boards/platforms (litex repository) and litex-board/plateforms (litex-boards) ? Some files are identical.

14:49 <acathla> _florent_?

15:50 <somlo> acathla: afaik, litex-boards is a super-set of litex/litex/boards

15:51 <somlo> it *used* to have things split into "official", "community", and "partner" to differentiate the levels of support for each category, and "official" was the same set as what's currently in litex/litex/boards

15:51 <somlo> but then _florent_ removed the official/community/partner distinction and now litex-boards is just "everything in upstream LiteX plus a bunch more"

17:07 <_florent_> acathla: litex-boards is indeed a super-set of the supported ones in LiteX. You could see the one in LiteX as the ones used for regression testing, we'll see in the future of we keep both or only litex-boards

17:08 <acathla> _florent_, ok

17:08 <acathla> _florent_, so if I want to add support for a new board, the best place is in litex-boards?

17:12 <_florent_> there was indeed a distinction in litex-boards, for level of support, but this was introducing more complexity and all platforms were maintained similarly, so i removed the distinction for simplicity

17:12 <_florent_> acathla: yes, litex-boards is the right place for new boards

17:14 <somlo> _florent_: I noticed the litesdcard nexys4ddr example uses S7PLL, but the litex builder uses S7MMCM

17:15 <somlo> wondering if that's why I'm getting timing issues when trying to add litesdcard to my litex EthernetSoC

17:17 <somlo> building the nexys4ddr litesdcard example works fine (no timing issues like when trying to add it to EthernetSoC in "upstream" litex)

19:05 <_florent_> somlo: sorry i haven't been able to look at the nexys4ddr design yet

19:05 <_florent_> you can maybe try to switch between S7MMCM and S7PLL

19:34 <somlo> _florent_: I did, the litesdcard example works with both, while the modified EthernetSoC doesn't like either :) I'm studying the clock situation (perhaps when adding litesdcard to "upstream" EthernetSoC we should generate its clock signal there and drop litesdcard.clocker)

19:36 <somlo> So if/when you have a chance to look and put me out of my misery, that's fine with me... I'll learn something either way (by digging around blindly until things start making sense, or by studying your patch that just fixes stuff) :)

21:48 <somlo> _florent_: so far, I believe that when I try to glue litesdcard into litex-proper's EthernetSoC, the litesdcard clocker module grabs the wrong ClockSignal() here: https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/clocker.py#L125

21:48 <tpb> Title: litesdcard/clocker.py at master · enjoy-digital/litesdcard · GitHub (at github.com)

21:50 <somlo> since EthernetSoC has a large number of clock domains, I think I end up getting something other than "clk100" (vivado complains that because CLKIN1_PERIOD = 33.33333, the output would be 192MHz which is way below the minimum 600MHz required by speedgrade -1)

21:51 <somlo> whereas when built as part of the litesdcard/examples/nexys4ddr.py, ClockSignal() is the one-and-only "clk100", and things work fine