_florent_ changed the topic of #litex to: LiteX FPGA SoC builder and Cores / Github : https://github.com/enjoy-digital, https://github.com/litex-hub / Logs: https://libera.irclog.whitequark.org/litex
tpb has quit [Remote host closed the connection]
tpb has joined #litex
Degi_ has joined #litex
eric_xt has joined #litex
Degi has quit [Ping timeout: 260 seconds]
Degi_ is now known as Degi
eric_xt has quit [Remote host closed the connection]
eric_xt has joined #litex
sebo has joined #litex
sebo has quit [Ping timeout: 246 seconds]
FabM has joined #litex
FabM has quit [Changing host]
FabM has joined #litex
sebo has joined #litex
eric_xt has left #litex [Leaving]
eric_xt has joined #litex
eric_xt has quit [Client Quit]
sebo has quit [Ping timeout: 272 seconds]
eric_xt has joined #litex
sebo has joined #litex
<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.
eric_xt has quit [Remote host closed the connection]
eric_xt has joined #litex
eric_xt has quit [Remote host closed the connection]
eric_xt has joined #litex
<sebo> I was thinking about the tul_pynq_z2...
sebo has quit [Ping timeout: 256 seconds]
sebo has joined #litex
sebo has quit [Remote host closed the connection]
sebo has joined #litex
Guest28 has joined #litex
<Guest28> Hi! Is there something like "make.py clean" to restart all the compilation?
<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.
C-Man has quit [Ping timeout: 246 seconds]
sebo has quit [Ping timeout: 260 seconds]
AndrewD has joined #litex
<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
<_florent_> AndrewD: Thanks, that's great!
<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.
<_florent_> AndrewD: gsomlo just also got the LiteSDCard driver merged in Linux a few days ago :)
<AndrewD> _florent_: great news on the Linux driver merge.
<_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?
<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:
<tpb> Title: SN65HVD230 – Kaufen Sie SN65HVD230 mit kostenlosem Versand auf AliExpress version (at www.aliexpress.com)
<_florent_> AndrewD: Thanks!
<_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
<_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 :)
<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
<AndrewD> expose a standard function that each module can provide. That would be quite elegant, but I haven't experimented with do this.
<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 :/
<_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)
<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.
Guest28 has quit [Quit: Client closed]
<_florent_> AndrewD: But happy to have it on litex-hub yes but probably renamed
<_florent_> AndrewD: The DTS support is indeed a bit experimental an regrouped in litex_json2dts script. Some parts could probably be exported to peripherals
<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 :)
<_florent_> AndrewD: But for now, we could still experiment in litex_json2dts
<_florent_> AndrewD: The CAN FD would also be a good example of external core integration we could redirect users/developers to
AndrewD81 has joined #litex
<_florent_> AndrewD: I'll think about the name
<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.
AndrewD has quit [Ping timeout: 250 seconds]
AndrewD81 is now known as AndrewD
<_florent_> tnt: Thanks for the test/feedback. I'm going to continue investigating.
eric_xt has quit [Remote host closed the connection]
eric_xt has joined #litex
<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.
<_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.
sebo has joined #litex
<tnt> I'm using vivado 2021.2 btw, not sure which version you test with, in case it makes a difference.
sebo has quit [Ping timeout: 246 seconds]
<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.
C-Man has joined #litex
<_florent_> AndrewD: I like it yes and this matches what I'm doing when testing external cores (ex litex_naxriscv_test, litex_neorv
<_florent_> litex_neorv32_test repo, etc...)
<_florent_> tnt: I'm using 2021.1, I'll see if I reproduce client's issue with it
<tnt> Could also be something specific to the host system I guess.
Guest28 has joined #litex
Guest28 has quit [Client Quit]
mtretter has quit [Remote host closed the connection]
sebo has joined #litex
mtretter has joined #litex
<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.
<sebo> here is the command I use: python3 -m litex_boards.targets.krtkl_snickerdoodle --build
<sebo> I get a bunch of errors about board unrelated:
<sebo> File "/home/sebo/Enjoy-Digital-Packaging/litex-boards/litex_boards/platforms/efinix_trion_t120_bga576_dev_kit.py", line 9, in <module>
<sebo> from litex.build.efinix.platform import EfinixPlatform
<sebo> ModuleNotFoundError: No module named 'litex.build.efinix'
<tnt> sebo: you probably have updated litex-boards without updating litex.
<sebo> mm. yes. I'll check.
<sebo> Nope.
<sebo> How do you keep your environment up tp date?
davebee has joined #litex
<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.
<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
davebee has quit [Client Quit]
<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.
davebee has joined #litex
<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.
<sebo> ok. My env. was messed up. Got it right now.
Guest28 has joined #litex
Guest28 has quit [Client Quit]
sebo has quit [Ping timeout: 256 seconds]
sebo has joined #litex
sebo has quit [Ping timeout: 260 seconds]
FabM has quit [Quit: Leaving]
davebee has quit [Quit: Client closed]
Martoni has joined #litex
Martoni has quit [Ping timeout: 260 seconds]
<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
<AndrewD> maintain the naming convention?
<tnt> you can't use - in python package names.
<tnt> hence ... litex_boards
AndrewD has quit [Quit: Client closed]