00:03 <vup> @EmilJ you have to make it use the zynq soc platform using "-s Zynq"

00:04 <vup> so in total something like `python3 src/experiments/hdmi_test.py -d Zybo -s Zynq -b` should work

00:04 <d1b2> <EmilJ> shouldn't a "platform" be bound to the SoC?

00:05 <vup> well we have platforms and soc's

00:05 <d1b2> <EmilJ> I mean, you are defining resources on a platform with how they are connected to pins on the SoC, in the SoC's naming scheme

00:05 <vup> the idea is, that soc's here define how CSR's can be read out

00:06 <vup> it is possible that one might not want to use the Zynq SoC on and Zynq fpga but instead use jtag to read ot the CSR's

00:06 <vup> s/ot/out/g

00:07 <vup> so we don't want to tightly couple a platform to a SoC type

00:08 <d1b2> <EmilJ> I'm getting lost in this abstraction - the assumption here being that JTAG can access arbitrary addresses in processor system memory maps?

00:08 <vup> no

00:09 <vup> the gateware can define registers that can be read out externally

00:09 <vup> how exactly those registers can be read out is defined by the choosen soc

00:09 <vup> if you choose the zynq soc you can read it out using axi

00:10 <vup> if you choose jtag, you can read it out over jtag (using some basic protocol we have defined for that)

00:10 <vup> now as you have found out, this is not very cleanly implemented right now and some things specifically depend on being used on a zynq, mainly because we haven't got to writing serdes and clocking / pll abstractions yet

00:11 <d1b2> <EmilJ> so, platform selection decides not only what resources are on-board, but also what synthesis happens to creat interfaces to your CSRs

00:12 <d1b2> <EmilJ> doesn't that still mean that selecting a platform asserts platform pinout namespace?

00:12 <vup> kind of, you select the interface to your CSRs using a seperate switch in the cli (the -s switch), but internally this is represented by wrapping the "hardware platform" with a wrapper that implements the stuff used for the selected CSR interface

00:13 <vup> what do you mean by that?

00:15 <d1b2> <EmilJ> if I look at, say, MicroZedZ020Platform which inherits from Xilinx7SeriesPlatform, I see it has a Connector, which translates pins such as "W18". The pinout naming of different SoCs is not going to be typically the same, so selecting a platform is already bound to a SoC

00:18 <vup> well the idea is that the pinout naming for compatible things should be compatible, so for example the ZyboPlatform has a resource named hdmi, that is compatible with the resource generated by the `hdmi_plugin_connect` call in the hdmi_test.py file

00:19 <vup> also a specific fpga doesn't really have only one possible way of interfacing with the CSRs

00:19 <vup> one might want to use jtag to read them out on a zynq for example (maybe because one has nothing actually running on the arm cores)

00:20 <d1b2> <EmilJ> okay, that makes sense

00:21 <vup> but yeah, as noted, this isn't all super clean right now and you actually have to use the Zynq CSR interface for the hdmi_test gateware, as the thing that provides access to the ps7 is not yet decoupled from the thing that implements the CSR interface

00:25 <d1b2> <EmilJ> Hmm... so if I look into hdmi_plugin_connect, I see references to things named "lvds0_p" - in what namespace do those exist? Does this function expect an, uh, virtual Connector to rewire the hdmi module to real pins on the FPGA?

00:27 <vup> if you take a look at the beta and the micro_r2 platform you cat see calls to `gen_plugin_connector` which generates those

00:27 <vup> basically its a just a header that different things can be connected to

00:33 <d1b2> <EmilJ> Should that layer exist even on devices that don't have physical modules?

00:34 <d1b2> <EmilJ> ooooh, so in beta_platform.py, the pin namespace is "enumerated pins on expansion connectors"

00:36 <vup> I don't think that layer should exist on devices that have no physical modules

00:37 <vup> So for example the Zybo has a hdmi connector and just has a resource that directly represents that

00:40 <d1b2> <EmilJ> Oh, okay

00:41 <d1b2> <EmilJ> I'll take another look at it tomorrow. It's almost 3am here

00:50 <vup> well same :)

12:54 <lkcl> erm... *puzzled*. how do you write simulations that involve 2 different clock domains?

12:54 <lkcl> i have a JTAG module to write, and it's self-clocked

12:55 <lkcl> however it connects to a different piece of logic that has a standard sync domain

12:56 <lkcl> but the "join" will obviously be via an AsyncFFSynchroniser

12:57 <lkcl> ... so how the heck... ahhh, "add_clock" can take a domain argument, which defaults to "sync"

12:57 <lkcl> def add_clock(self, period, *, phase=None, domain="sync", if_exists=False):

12:58 <lkcl> ssooOoooOoo... i am guessing that in each process... ah!

12:58 <lkcl> class Tick(Command):

12:58 <lkcl> def __init__(self, domain="sync"):

12:58 <lkcl> therefore if i do "yield Tick("jtag_domain")" that should do the trick

14:20 <lkcl> ha! that seemed to work pretty well https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/test/async_sim.py;hb=HEAD

14:21 <lkcl> the only thing unexpected is that one of the counters appears to be running 33% faster than the clock domain it's operating in.

14:21 <lkcl> whitequark: ^ ? curious

18:38 <lkcl> ahhhh found the problem. sim.add_clock(xxx, domain="something")