07:02 <sebo> Hello, I have a Trenz Zynqberry board. i'd like to add support of this board in the litex-boards repository. Any board similar to this one I could use as an example from? Thanks.

07:05 <sebo> I was thinking about the tul_pynq_z2...

08:04 <Guest28> Hi! Is there something like "make.py clean" to restart all the compilation?

08:06 <tnt> sebo: Even if there is no "close" board, really any board that has zynq would be a good example, then just look at any board for example of peripheral X / Y and how to add it.

09:01 <AndrewD> _florent_: LiteSDCard Nuttx driver has been merged into Nuttx - as you saw on twitter: https://twitter.com/rtlmeta/status/1509084289178419200?s=20&t=NvjgNeJcFfg_DKWtoj_hxg

09:02 <_florent_> AndrewD: Thanks, that's great!

09:05 <AndrewD> _florent_: I've also done some more work on the litecan integration of the CAN FD core and linux driver for ctucanfd. I fixed some bugs in the driver to get CAN Tx working and today I fixed the final issue in the litecan integration so CAN Rx also works. The interface is now fully functional, just needs some stress testing.

09:05 <_florent_> AndrewD: gsomlo just also got the LiteSDCard driver merged in Linux a few days ago :)

09:06 <AndrewD> _florent_: great news on the Linux driver merge.

09:07 <_florent_> AndrewD: That's also nice for the CAN, I would be curious to explore CAN a little bit, are you using a specific hardware for the CAN interface?

09:18 <AndrewD> _florent_: we have a custom board that has a 3V3 CAN phy and some other physical layers we wanted to test. With the linux driver you can use loopback to do really basic testing too. Something like this connected to PMOD would also work:

09:18 <AndrewD> https://www.amazon.com/waveshare-SN65HVD230-Transceiver-Communication-Development/dp/B076NRGCKY/ref=sr_1_4?keywords=SN65HVD230+Module&qid=1648631833&sr=8-4

09:19 <AndrewD> _florent_: or https://www.aliexpress.com/wholesale?SearchText=SN65HVD230

09:19 <tpb> Title: SN65HVD230 – Kaufen Sie SN65HVD230 mit kostenlosem Versand auf AliExpress version (at www.aliexpress.com)

09:20 <_florent_> AndrewD: Thanks!

09:25 <_florent_> AndrewD: BTW, regarding litecan name, maybe something like ctucanfd_litex_wrapper would be more appropriate since that's in fact a wrapper around CTU CAN FD core

09:28 <_florent_> AndrewD: I think it would reflects things more clearly for users and for the authors of the CTU CAN FD core, and this also let use the possibility later to really develop a real LiteCAN core :)

09:33 <AndrewD> _florent_: Litecan made sense to me because some other lite* peripherals also looked like wrappers. I really don't care what it's called, but would like to see it available on litex-hub if possible and the DTS support integrated into litex. Regarding DTS I've wondered if the DTS generation for a peripheral should reside with the peripheral and just

09:33 <AndrewD> expose a standard function that each module can provide. That would be quite elegant, but I haven't experimented with do this.

09:34 <tnt> _florent_: btw, tried with litex updated too, but still same behavior, so something else is going on that will need digging into at some point :/

09:36 <_florent_> AndrewD: the other litex* peripherals are not wrapper, they are providing the core logic (except for some of them the PHY that can be a hardblock)

09:36 <AndrewD> _florent_ someone started writing exactly the same thing but abandoned it when he found my implementation, so public CAN bus support for Litex would be useful. It was a key feature I was looking for when researching using FPGA in our porduct.

09:37 <_florent_> AndrewD: But happy to have it on litex-hub yes but probably renamed

09:38 <_florent_> AndrewD: The DTS support is indeed a bit experimental an regrouped in litex_json2dts script. Some parts could probably be exported to peripherals

09:38 <AndrewD> _florent_ OK, I stand corrected. I was probably mixing this though up with the cpus, etc. If you propose a name you are happy with I'll rename it, but ideally not crazy-long :)

09:38 <_florent_> AndrewD: But for now, we could still experiment in litex_json2dts

09:39 <_florent_> AndrewD: The CAN FD would also be a good example of external core integration we could redirect users/developers to

09:42 <_florent_> AndrewD: I'll think about the name

09:43 <AndrewD81> _florent_: OK. Got to run but I think my integration is already there on my litex fork, I'll tidy it up and do a PR when it's time to round this out.

09:45 <_florent_> tnt: Thanks for the test/feedback. I'm going to continue investigating.

09:46 <tnt> _florent_: if there is any internal signal I should probe with litescope to get a better idea of what could be going wrong, I can have a look at that.

09:50 <_florent_> tnt: in fact I should be able to reproduce. I'm no longer able to reproduce it with a direct LiteX build but a client that is reintegrating the LitePCIe standalone core in a Vivado design still see the issue and shared the project with me so I should be able to probe things directly.

09:54 <tnt> I'm using vivado 2021.2 btw, not sure which version you test with, in case it makes a difference.

10:00 <AndrewD> _florent_: how about just litex-ctucanfd? it's a litex wrapper for that ip core and is already imported as ctucanfd. This could be a generic naming convention for wrappers. The description of the repository is then just an expansion of the name.

10:05 <_florent_> AndrewD: I like it yes and this matches what I'm doing when testing external cores (ex litex_naxriscv_test, litex_neorv

10:05 <_florent_> litex_neorv32_test repo, etc...)

10:08 <_florent_> tnt: I'm using 2021.1, I'll see if I reproduce client's issue with it

10:30 <tnt> Could also be something specific to the host system I guess.

12:45 <sebo> tnt: ok. Before starting anything, I'm trying to give a try on an existing board. And, it looks like something is messed up.

12:46 <sebo> here is the command I use: python3 -m litex_boards.targets.krtkl_snickerdoodle --build

12:47 <sebo> I get a bunch of errors about board unrelated:

12:47 <sebo> File "/home/sebo/Enjoy-Digital-Packaging/litex-boards/litex_boards/platforms/efinix_trion_t120_bga576_dev_kit.py", line 9, in <module>

12:47 <sebo> from litex.build.efinix.platform import EfinixPlatform

12:47 <sebo> ModuleNotFoundError: No module named 'litex.build.efinix'

12:50 <tnt> sebo: you probably have updated litex-boards without updating litex.

12:50 <sebo> mm. yes. I'll check.

12:56 <sebo> Nope.

12:56 <sebo> How do you keep your environment up tp date?

13:05 <tnt> Depends how yo installed I guess ... usually I just do manual pulls of the various repo just because I want to see what changed. I think the litex_setup thing has an update command doing it all at once.

13:07 <DerekKozel[m]> the litex_setup tool has been pretty robust for me. It does pull in a lot of repos, but does do a good job of grabbing it all-in-one go

13:09 <sebo> I used it as well but I realized one time that the litex repo was not properly updated and I had to do it manually.

13:15 <davebee> _florent_: Thanks for your help yesterday connecting an Amaranth wishbone bus to Litex. It is now working. I was stumped for a while, but discovered that the Litex wishbone interface was 30-bits wide and the Amaranth Decoder was 32-bits wide. Once I realised this I just padded the bottom 2 bits and it is now working. Many thanks.

13:52 <sebo> ok. My env. was messed up. Got it right now.

19:26 <AndrewD> _florent_: in litex-hub most repos use '-' as the separator, for example litex-boards but they sometimes have '_' as a directory name, so litex-boards repo has a litex_boards directory. I'm proposing to use litex-ctucanfd as the git repo name, just need to think about internal structure a bit. Should there be a litex_ctucanfd subdirectory to

19:26 <AndrewD> maintain the naming convention?

19:32 <tnt> you can't use - in python package names.

19:32 <tnt> hence ... litex_boards