07:51 <_florent_> tcal: yes exactly, doing the CFU instance in the do_finalize will allow you to update self.cfu_params from your user design, method calls, etc...

07:54 <_florent_> tnt: You can indeed simplify the clocking, this design supports 2 JESD linerates (transceivers reconfigured over DRP), I removed the DRP part before sharing but forgot to simplify the clocking.

07:55 <tnt> _florent_: thanks for confirming. Now I gotta make it work on USP, looks like it doesn't accept the GTH3 primitives, gotta make them GTH4.

08:00 <_florent_> tnt: Indeed, if seems LiteICLink currently only supports GTHE3/Ultrascale and GTYE4/UItrascale+

08:02 <tnt> Yup that's unfortunate because looking at those files, it seems insanely complex.

08:10 <tnt> _florent_: you don't happen to have the xci file that was used to get the original transceiver config ?

08:12 <tcal> _florent_: yep, that works for me! PR incoming.

08:20 <_florent_> tnt: I should have it and will try to find it. I think GTHE3/GTHE4 are very similar, to get a first idea about this, could you generate the default transceiver wizard configuration for both and compare the generated files? (and GTHEX instances?)

08:23 <tnt> They definitely look very similar and even explained in the same document with the same tables with just some notes about "Ultrascale only" / "Ultrascale+ only" but there are a bunch of "reserved values" in those differences.

08:42 <tnt> _florent_: I generated both in default config. Unfortunately some of the magic values are different :/

08:52 <tnt> I'll make a table comparing both along with the "default" values of the params you find in the sim model.

09:16 <_florent_> tnt: OK, I'll also have a look

10:39 <tnt> _florent_: https://people.osmocom.org/~tnt/stuff/gthe_common.html

10:39 <tpb> Title: GTHE3/4 compare (at people.osmocom.org)

10:39 <tnt> first draft

10:41 <tnt> (just for COMMON atm)

11:13 <tnt> And same for channel : https://people.osmocom.org/~tnt/stuff/gthe_channel.html

11:13 <tpb> Title: GTHE3/4 compare (at people.osmocom.org)

11:14 <tnt> Now "just" need to analyze them and figure out what's needed.

13:09 <tnt> There are a bunch of params that have a _G3 suffix, any clue what that means ?

13:50 <_florent_> tnt: thanks, sorry I'm not able to help much now (busy on something else), but maybe you could start adapting the instance (remove the parameters that are specific to GTHE3, add the ones that are specific to GTHE4), same for signals and we could then have closer look together at the differences/parameters. This should also allow you to test design compilation.

13:59 <tnt> _florent_: yeah, working on that right now. This is what it looks like ATM: https://pastebin.com/WQtN3jR5

13:59 <tpb> Title: diff --git a/liteiclink/serdes/gth_ultrascale.py b/liteiclink/serdes/gth_ultrasc - Pastebin.com (at pastebin.com)

13:59 <tnt> (completely untested ... obviously )

14:05 <_florent_> tnt: Looks good. Before testing JESD with this wrapper, we'll probably be able to do a first simple test with liteiclink examples

14:06 <_florent_> tnt: with the internal loopback, at various rates and eventually with others boards if you (or I) have boards with some GTHE4 transceivers exposed to some connectors

14:07 <_florent_> tnt: This way the link will validated before being integrated for JESD

14:08 <tnt> _florent_: Ack. Probably a good idea indeed :)

21:22 <paul-web> Has there been any thought for including ARM Cortex-M processors with the understanding the user would be responsible to provide the SDK.

21:22 <paul-web> It's freely available (as in beer) via Arm DesignStart (both M1 and M3). From my brief look it doesn't seem like a giant leap to support given the framework already in place

21:22 <paul-web> or am I just way underestimating the amount of work required?

22:09 <bjonnh> oh my… the UART in connected to the PS and not the PL

22:09 <bjonnh> that's not going to be fun

22:16 <tnt> bjonnh: lol, had the same thing recently ... ended up putting a usb->serial on some random gpio because you can't connect MIO pins to the PL.

22:17 <bjonnh> of course I don't have that

22:17 <bjonnh> I was thinking about flashing the PS with something that would do that

22:17 <bjonnh> which mean that I have to learn how that PS work

22:19 <tnt> yeah, you could use one PS uart connected to MIO, another one connected to the PL and then have a software running shuffling chars arounds. That would work I guess. Painful, but that would work.

22:20 <tnt> What board is it btw ?

22:31 <bjonnh> Arty Z7-20

22:31 <bjonnh> but I don't understand it seems that to use the PS I need to have some stuff ready in the PL

22:31 <bjonnh> which mean that I may not be able to do that with symbiflow, yosys etc

22:32 <bjonnh> tbh I don't know how most of that work just yet

23:00 <tnt> Mmm .. no the PS can work independently from the PL.

23:00 <tnt> Specifically to support systems where the PS is the one loading the PL.

23:02 <bjonnh> ok I have to investigate that further then