09:31 <d1b2> <sarea> regarding different clock domains, I think the setup and syncing to externally provided CLK seems pretty clear (works). what I'm wondering though: since the FIFO works with 48 MHz (clk_if) and it does not seem to be possible to change that, it is apparent that for any externally provided CLK that is conditioned by a PLL (-> new internal CLK domain), a clock domain crossing is necessary between the 48 MHz clk_if domain and the PLL-generated CLK

09:31 <d1b2> domain; what is the best strategy to achieve that? is there some nmigen magtic to do that easily or do I need to do this manually for the FIFO and I2C signals? I think that is quite cumbersome and would limit using externally generated CLKs ... application background: feed in 10 MHz reference signal from OCXO to achieve long-term stability for measurement related stuff

09:32 <whitequark> there's an async FIFO feature but it doesn't quite work yet

09:32 <whitequark> it's been on the TODO list to fix that for a while; in fact it was one of the original motivations for nmigen!

09:36 <d1b2> <sarea> :*-(

09:36 <d1b2> <sarea> bummer

09:36 <d1b2> <sarea> can I help with that?

09:37 <whitequark> not really

11:08 <d1b2> <kbeckmann> What are the current limitations with AsyncFIFO in nMigen today? I wrote an applet that samples external signals with an external clock, and sends those samples back to the host. This is done by creating the ClockDomain object in the build() function, and passing it to both the applet and as a parameter to get_in_fifo(). I connect the clockdomain to the external clock signal in the applet's elaborate function. It might be a bit of a hack, but

11:08 <d1b2> it seems to work. If there is a better approach, I'm all ears. @sarea If you want to look at the code for inspiration I have it here https://github.com/kbeckmann/Glasgow/blob/kb/n64/software/glasgow/applet/n64/n64video/__init__.py

12:06 <d1b2> <sarea> hm perhaps it is possible (as a start only) to 'overwrite' the normal sync domain with the 48 MHz generated from the PLL? I just can't seem to find where the CLK is initially claimed ... because that is the spot where I would like to replace it with the PLL-generated version; that way I would avoid any cross domain issues with the FIFO/I2C

12:06 <whitequark> kbeckmann: the resets

12:07 <whitequark> sarea: you'd have to patch some of the core components in an invasive way, but yes, it's technically possible

12:08 <d1b2> <sarea> Glasgow or nmigen core components? 😆

12:08 <whitequark> glasgow

12:08 <whitequark> oh, and you'll likely have timing issues with the FX2 interface

12:09 <d1b2> <sarea> but why? if I use a highly stable 10 MHz external ref, generate 48 MHz from that with the PLL, it should be OK; no?

12:10 <whitequark> there's a few issues

12:10 <whitequark> first, you can only get 48.125 MHz with the iCE40 PLLs, not 48 MHz

12:12 <whitequark> second, the setup/hold times for SB_IO and the FX2 are different depending on whether FX2 sources or accepts the clock

12:13 <whitequark> there should be a timing analysis for that part of the interface somewhere on GitHub; the margins on it are very tight and you'll definitely have to modify the part of the design that talks to the FX2

12:13 <d1b2> <sarea> ah I see, so the default clock of the ice40 is provided by the FX2?

12:13 <whitequark> yes

12:13 <whitequark> this is done to free both of the PLLs for user designs

12:13 <d1b2> <sarea> ah okay; so then it does not work; agreed

12:14 <whitequark> though placement restrictions make that a lot trickier than originally planned

12:14 <whitequark> the iCE40 does not have a stable clock source, so it would have to accept the clock from the FX2 or something else on the board anyway

12:15 <d1b2> <sarea> okay, so for testing I guess I will just remove the oscillator for the FX2 and feed in the 24 MHz directly; no programming -- 100% hardware solution 😆

12:16 <whitequark> yep that sounds nice and straightforward

12:16 <d1b2> <sarea> 👍