The new Real-Time HAT by InnoRoute adds IEEE1588 PTP support in hardware to a Raspberry Pi 4 nestled beneath. Based around a Xilinx Artix-7 FPGA and a handful of gigabit Ethernet PHY devices, the HAT acts as network-passthrough, adding accurate time-stamps to egress (outgoing) packets and stripping time-stamps from the ingress (incoming) side.
This hardware time-stamping involves re-writing Ethernet packets on-the-fly using specialised network hardware which the Raspberry Pi does not have. Yes, there are software-only 1588 stacks, but they can only get down to 10s of microsecond resolutions, unlike a hardware approach which can get down to 10s of nanoseconds.
1588 is used heavily for applications such as telecoms infrastructure, factory equipment control and anything requiring synchronisation of data-consuming or data-producing devices. CERN makes very heavy use of 1588 for its enormous arrays of sensors and control equipment, for all the LHC experiments. This is the WhiteRabbit System, presumably named after the time-obsessed white rabbit of Alice In Wonderland fame. So, if you have a large installation and a need for precisely controlling when stuff happens across it, this may be just the thing you’re looking for.
IEEE1588 PTP Synchronisation
The PTP client and master device ping a few messages back and forth between themselves, with the network time-stamper recording the precise moment a packet crosses the interface. These time-stamps are recorded with the local clock. This is important. From these measurements, the time-of-flight of the packet and offset of the local clock from the remote clock may be calculated and corrected for. In this way each client node (the hat) in the network will have the same idea of current time, and hence all network packets flowing through the whole network can be synchronised.
The beauty of the system is that the network switches, wiring and all that common infrastructure don’t need to speak 1588 nor have any other special features, they just need to pass along the packets, ideally with a consistent delay.
The Real-Time HAT configures its FPGA via SPI, straight from Raspberry Pi OS, with multiple applications possible, just by a change on the command line. It is possible to upload custom bitstreams, allowing the HAT to be used as a general purpose FPGA dev board should you wish to do so. It even stacks with the official PoE HAT, which makes it even more useful for hanging sensors on the end of a single wire.
Of course, if your needs are somewhat simpler and smaller in scale than a Swiss city, you could just hack a GPS clock source into a Raspberry Pi with a little soldering and call it a day.
Very nice, but it’s a shame you have to add a complex hat just for PTP. If I am not mistaken, adding PTP support to an Ethernet chip requires very little additional logic, so it could just work out of the box if the RPi foundation would have chosen a supported chip.
Yes. This exactly. Curiously the CM4 has such a chip. Although the datasheet says it supports 1588, the drivers aren’t currently there, yet. I believe it is currently being worked on.
Yup, it amazes me that PTP support on the RPi requires additional stuff. It should work straight out of the box.
This is a thing that gets me about the SBC ecosystem- people just dont allow for the evolution, they expect top-tier turnkey for every application now or yet conceived. Everything should be now and already in the box waiting to be unleashed.
Take the CM1… Still impressive for the time and what it was. Not near as polished or capable as the CM4, but the idea is still there. Archaic or not, in just a few years and iterations.
Yeah… I’m shocked that it’s only now finally getting into what would seem to be basic storage tech, but whatever the pi5 brings on that front I’ll still have my quad-sata NAS.
I believe the same NIC/PHY is used on both the RPI4 and CM4 and it *is technically capable* of PTP 1588:2008.
On the RPI4 I do not know if the correct pins are broken out, however, so it may need to rely on a software implementation.
On the CM4 the additional NIC pins are broken out to a header on the Compute Module IO Board, so it should be possible here, but again, when I went looking for a datasheet there is precious little information available.
Also, I am almost certain that unless something large has changed you do need all devices in the path to support PTP, as packet timestamps need to be updated at each device including switches and routers or you lose the determinism that this technology maintains over the older and simpler NTP standard.
https://www.thebroadcastbridge.com/content/entry/10287/ptp-transparent-versus-boundary-clock-in-broadcast-environments
https://www.thebroadcastbridge.com/uploads/content_images/Embrionix_IP_reference_clock_AT_figure_1.png
http://digitalsubstation.com/en/wp-content/uploads/sites/2/2016/11/figure-5.jpg
There are starting to be much cheaper options for smaller PTP-capable switches though.
In fact, the Microchip KSZ9477 and family are cheap enough that this is a PTP-homelab territory. (About $20 for the switch chip alone, you just need a crystal, possibly a controller, and all of your power and magnetics. ;) )
> all devices in the path to support PTP, as packet timestamps need to be updated at each device including switches and routers or you lose the determinism that this technology maintains over the older and simpler NTP standard.
There’s also NTP-over-PTP and HW timestamped NTP, so in some cases the difference actually isn’t that large. Especially considering NTP can kind-of handle network jitter better. Also NTPv4 was published in 2010 and PTPv2 in 2008.
I believe the same NIC/PHY is used on both the RPI4 and CM4 and it *is technically capable* of PTP 1588:2008.
On the RPI4 I do not know if the correct pins are broken out, however, so it may need to rely on a software implementation.
On the CM4 the additional NIC pins are broken out to a header on the Compute Module IO Board, so it should be possible here, but again, when I went looking for a datasheet there is precious little information available.
Also, I am almost certain that unless something large has changed you do need all devices in the path to support PTP, as packet timestamps need to be updated at each device including switches and routers or you lose the determinism that this technology maintains over the older and simpler NTP standard.
https://www.thebroadcastbridge.com/content/entry/10287/ptp-transparent-versus-boundary-clock-in-broadcast-environments
https://www.thebroadcastbridge.com/uploads/content_images/Embrionix_IP_reference_clock_AT_figure_1.png
http://digitalsubstation.com/en/wp-content/uploads/sites/2/2016/11/figure-5.jpg
There are starting to be much cheaper options for smaller PTP-capable switches though.
In fact, the Microchip KSZ9477 and family are cheap enough that this is a PTP-homelab territory. (About $20 for the switch chip alone, you just need a crystal, possibly a controller, and all of your power and magnetics. ;) )
We have Ethernet PHY supporting IEEE 1588 time stamping while transmitting data. These provides better accuracy and don’t need any support on the SoC MAC. Refer to DP83630 & DP83640 on ti.com
https://www.ti.com/product/DP83630
Regards,
Geet
Could the FPGA be used as a hardware accelerated router? An open source very high performance router would be a great idea. With a sufficiently powerful FPGA, even hardware accelerated VPN should be possible.
Look into NetFPGA, which is exactly this.
Looks quite dated, perhaps time for a more modern version with more modern hardware focusing on high end home networking and small businesses?
I had a look at the site of this company and I think the HAT is more proven for upcoming industrial communication protocols in particular Time-Sensitive Networking (TSN – who dont know, it offeres deterministic communication based on standard ethernet), so it makes sense to have the time controlled by PTP in the FPGA. Therefore the article should have a different focus, because the fascinating thing is the Raspberry Pi industrial TSN grade communication, what this HAT enables. That’s cool! I wonder what the price is on the HAT. A price quote would be welcome :-)
If you can lay your hands on 250,000 chips of the more modern hardware (affordably), go for it!
And yet, the Raspberri Pi doesn’t even come with a RTC. LOL!
Personally, I don’t want an IOT that will fail to function, leaving the world dead in its tracks without an internet connection. RTCs are cheap for the Pi, and they will keep all the dates from being crashed.
1588 ensures that all devices are synchronised together so they maintain the same time. RTC’s will not do that because however good they are individually they will each will drift at a different rate over time.
NTP will keep you synchronised to a certain level, but if you want to maintain time sync to nsec level you need 1588 support (plus compatible switches etc).
Hi, this is the InnoRoute team and We really love HACKADAY. We are replying to some the questions:
* Generally speaking, if using standard NTP you can synchronize multiple devices in the millisecond range, if using a pure software-based PTP solution it is the microsecond range, and if using additional hardware support, e.g. the HAT, you can get into the nanosecond range, but you need support from your switches as well (they need to act as “transparent bridges”)
* Why would anybody use this accuracy and precision? If you want to trigger events at predetermined times or want to merge freely sampled data, e.g. move multiple axes by a certain degree at the same time or correlate sound samples from multiple distributed microphones, then you need a good synchronization, but the numbers all depend on your application’s requirements
* Why is the hardware clock not contained in the Ethernet PHY of the Raspberry PI? Cost: it’s the few additional cents needed to include this functionality that most users would not even be aware of
* Is the HAT only targeted towards industrial applications? No, but many users in industrial networking or automotive networking domains use it to connect devices
* The Real-Time HAT is more than just time synchronization with PTP. As a commenter correctly identified earlier, the HAT has Time-Sensitive Networking (TSN) support. TSN Mechanisms benefits from the highly accurate time synchronization.
* Why did InnoRoute build the HAT? Originally, we created a low-cost alternative to our high-end industrial Ethernet/TSN router, but we also saw that there is demand for a general purpose FPGA HAT with Ethernet ports, for powerful network monitoring on a small Raspberry PI, for hardware-accelerated routing and for other applications.
Should of led with TSN support. That’s really useful
“general purpose FPGA HAT with Ethernet ports, for powerful network monitoring on a small Raspberry PI”
This sounds cool and all, but the HDL isn’t available on github–arguably the most important part of buying/considering a device like this.
Is it available anywhere?