02:42 <whitequark> yep, whta kmc said is correct. syncing to an external 10 MHz reference clock is definitely doable; syncing between two devices (where one sources SYNC and other accepts) is what's not really proven

03:00 <levi> I worked on FPGA-based devices that did that sort of synchronization for the pro audio/video market. They usually had VCXOs with which they could sync up the local sample clock to a peer on a network. Worked really well for audio and video sample rates, at least.

03:13 <kmc> hmm, a future Ethernet-based Glasgow could implement IEEE 1588 for microsecond-level sync without an extra cable :)

03:14 <levi> These systems tended to use a 25MHz local oscillator as the main system clock, but used a 24.576 (or similar) VCXO as the master clock for media sampling. IEEE1588-based time sync and timestamping of samples were used to create a software-controlled control loop to sync the VCXO with whichever device was in charge.

03:16 <levi> CERN's White Rabbit project has really tight synchronization based on IEEE-1588, and it's Open Hardware apparently. Probably not in budget for a Glasgow-type device, but IEEE-1588-capable parts are way more common than you might think and it's not a particularly expensive feature.

03:18 <whitequark> White Rabbit is a bit overkill for what Glasgow wants to be, but yeah, I'm aware of it

03:19 <whitequark> for revCD, the fairly primitive ~SYNC pin mechanism is sufficient I think; USB has serious issues with meeting precise timing in any case

03:22 <levi> If you can distribute a reference clock everyone can just directly use, that's definitely way simpler than 1588-based solutions. I spent so much time on those, though, it's hard not to reach for it. :P

03:45 <d1b2> <uep> there are two cases here, though. sync as, basically, external event trigger (like with an OSC or LA), and sync as clock/training (like with GPS PPS)

03:46 <d1b2> <uep> I'm sure both are doable and have their place

04:18 <kmc> levi: yeah I only learned about the hardware aspect of 1588 recently because I was reading Raspberry Pi CM4 docs for some reason and their PHY supports the SYNC in/out

04:20 <d1b2> <Darius> is thankful 10MHz reference clock and 1PPS sync is enough for his needs

04:20 <d1b2> <Darius> nice and simple [mostly] 😅

06:24 <d1b2> <Hardkrash> I'm looking into IRIG-G and 10MHz GPSDO

06:24 <d1b2> <Hardkrash> maybe IRIG-B

09:09 <d1b2> <Darius> we have some SRS PRS-10s at work for bistatic radars 😄

09:09 <d1b2> <Darius> they cost a bit more though

09:11 <d1b2> <Darius> we've also been playing with http://www.jackson-labs.com/index.php/products/lte_lite

10:15 <d1b2> <cfy_yfc> great to hear; I'm mostly interested in providing an external 10 MHz reference input for having a more stable external reference (OCXO); for me only long-term relative stability matters and that digital I/O can be sent/received on a cycle-accurate basis in combination with a scope; there is no need for a GPSDO and absolute stability in terms of current time/date; even though there is really no difference for as long as it is possible to feed in a 10

10:15 <d1b2> MHz square signal

10:17 <d1b2> <cfy_yfc> the use case would be e.g., having an AWG to provide an unusual CLK input to the MCU (e.g., 133.7 MHz) while at the same time, providing a 10 MHz output to the Glasgow Explorer and a Scope, such that the whole setup is synced

10:19 <whitequark> yes, it is definitely possible to use a 10 MHz reference on SYNC pin to generate cycle-accurate digital IO waveforms, provided that you can eat worst case unbounded FIFO latency

10:19 <d1b2> <cfy_yfc> is there already an nmigen example on how to make use of the PLL in Glasgow? I was playing a little bit with CLK outputs on its I/Os and could not exceed 24 MHz ... as the main clock appears to be 48 MHz .... the crowdsupply campaign says it is good for up to 100 MHz and I wanted to test that (I have a revC2 at hand)

10:20 <whitequark> take a look at the VGA applet

10:20 <whitequark> that has an example of PLL instantiation

10:20 <d1b2> <cfy_yfc> thanks! will do

17:07 <d1b2> <j4cbo> IEEE 1588 seems to be pretty common in microcontroller MACs, but I thought the switch side of it was still pretty rare and pricey?

17:09 <electronic_eel> iirc you can do 1588 without support from the switch. then you get a bit more jitter, but you don't need a pricey / rare switch with full 1588 support

17:18 <gruetzkopf> yup, works well enough

18:02 <d1b2> <theorbtwo> Annoyingly, my scope is based on the iMX286, which has 1588 support, but the scope's spftware does not.

19:03 <kc8apf> Hardkrash: I sold off my IRIG-B time code generator.....

21:32 <levi> Switch ICs with 1588 support aren't terribly pricey or rare, it's commercial products with the combo of hardware support and firmware that does anything with it that are pricey/rare. The hardware aspect of it is pretty simple & small and anyone with an automotive or industrial control product line has the IP and integrates it with any switch or MAC part that might sell into those spaces as a matter of course now, AFAICT.

21:40 <adamgreig> I wish full 1588 support was more prevalent in basic switches, alas

21:41 <adamgreig> Still even with no switch support you can generally get 100ns or better for devices on the same switch

21:41 <adamgreig> Sure is a lot of work between "having timestamps on packets" and working synchronised clocks though

21:42 <levi> Haha, you're not kidding about that.

21:44 <levi> I spent 10 years working with a group involved in IEEE 802.1 Audio Video Bridging/Time Sensitive Networking standardization and applications for it in pro & automotive audio.

21:46 <levi> We tried really hard to get 1588 (at least the profile of it used for AVB) more prevalent in basic (or at least prosumer-level) switches. We even got a branded version of a Netgear switch with custom firmware extensions made, and wow, that was crazy.

21:48 <adamgreig> Gosh I bet. That would have been a nice future.

22:36 <levi> If you wanted to design your own 1588-capable small port count switch, this seems like a good starting point: https://www.microchip.com/wwwproducts/en/KSZ9477 The datasheet looks complete enough to write management code for, anyway, and unlike Marvell/Broadcom switches, it doesn't require an NDA.