Stefan Blixt är civilingenjör från Chalmers och processorarkitekt och CTO på Imsys, som har en processor med inbyggt stöd för IEEE 1588. Stefan Blixt är en av Imsys grundare och har konstruerat åtta olika processorer under sin karriär. Han var också en av grundarna av Versal AB som utvecklade och tillverkade displayterminaler.

PTP blev standard 2002 och en nyrevision blir klar i år. Protokollet är oberoende av nätverksteknologi men förutsätter att löptiden mellen två noder normalt är lika i båda riktningarna. Nedan antas att TCP/IP över Ethernet används. Med IP-protokollet kan alla anslutna noder kommunicera oberoende av hur den fysiska Ethernethopkopplingen struktureras.

PTP bygger en egen trädstruktur av master-slave-relationer mellan noderna, för att en utvald nod, kallad grandmaster (GM) skall kunna bestämma vad som är korrekt tid. GM har normalt en högstabil oscillator och kan ha sin klocka låst till en tidssignal från en inbyggd GPS-mottagare. Därmed kan alla klockor i nätverket bli synkroniserade till en gemensam referens, till exempel UTC, vilket kan vara värdefullt av till exempel juridiska skäl.

I vissa applikationer är en lokal tidsreferens fullt tillräcklig - det gäller till exempel för en grupp av samarbetande maskiner utan tidskritisk koppling till något utanför gruppen. Ibland är klockans hastighet, det vill säga frekvensen, viktigare än tiden. PTP kan användas för att noggrant och till låg kostnad hålla en frekvens på rätta värdet, för att till exempel syntetisera radiofrekvenser i en basstation.

Standarden beskriver hur synkronisering sker genom speciella meddelanden mellan master och slav och en metod för att beräkna skillnader i hastighet och fas hos klockor.

Meddelandena är UDP-paket i Ethernet-frames. Tidsstämpling sker av vissa meddelandetyper, och den skall helst göras i Ethernethårdvaran, i gränssnittet mellan Media Access Control (MAC) och den fysiska anpassningskretsen (PHY).

Mjukvara i slavklockan utför beräkningarna, filtrerar fas- och frekvensfelsignalerna och justerar slavklockan så att felen håller sig inom snäva gränser. Algoritmerna måste vara sådana att låsning kan ske tillräckligt snabbt men att när man väl har låst utnyttjar det faktum att källan är mycket stabil och de förändringar man skall kompensera för bara är den egna klockans långsamma drift; man måste sortera bort de mätningar som påverkas av kollisioner i nätet och tolerera att det ibland blir fel i överföringen.

En slav kan vara master för en annan slav och kallas då för en Boundary Clock (BC). En BC har en nätverksport med slavfunktion som styr en lokal klocka, samt dessutom en eller flera portar med masterfunktion, som distribuerar den lokala klockans tid i stället för att förmedla PTP-meddelanden mellan de två sidorna. I version 2 av PTP kommer det även att finnas en så kallad Transparent Clock, TC, som kan ersätta en BC i nätverksenheter som till exempel Ethernet-switchar.

En TC har ingen egen klocka, och den blockerar inte PTP-meddelanden mellan mastern på ena sidan och slavarna på den andra. Däremot kompletterar den dessa med data om sin egen fördröjning, vilket slavar ”nedströms” kan ta hänsyn till i sina beräkningar. Denna information kan ackumuleras, det vill säga det blir möjligt att justera även för flera TC i kedjan mellan master och slav.

Imsysbaserad PTP-slav

Som framgått ovan är det hos slaven som beräkningarna görs. Den kombination av hård- och mjukvara som beskrivs här är tillämplig även för en master clock, och därmed också boundary clock (Imsysprocessorn har två Ethernetkanaler).

Ethernet MAC finns på Imsys processor, realiserad dels i logik och dels i mikrokod (se nedan). Detta underlättar åtkomst av de signaler som behövs, och möjliggör tillräckligt snabbt åtgärdande av PTP-meddelanden, vid sidan om TCP/IP-stacken.

Dessutom finns 8 flexibla timers, som konfigureras som högfrekvent räknare, register för tidsstämpling, samt ytterligare räknare och register för generering av tidsexakta utsignaler.

Figur 3 illustrerar det Imsys-baserade IEEE1588-systemet och färgerna visar hur olika delar är implementerade - logik blått, mikrokod gult och mjukvara grönt.

Mikrokod, som används i vissa processorer (så kallade CISC) är normalt lagrad i ROM, men Imsysprocessorn har en stor del av sin mikrokod i skrivbart RAM ombord. Det är främst detta som gör det möjligt att utveckla specialfunktioner som IEEE 1588, och det ger också den flexibilitet som behövs när standarden vidareutvecklas.

All hårdvara och mikrokod i figur 3 finns ombord på processorkretsen, och det kompletta systemet, med programvaran, finns som en kompakt modul (24 5 45 mm). Detta system har visats kunna synkronisera med en standardavvikelse på mindre än 2 nanosekunder.

I det patentsökta Imsys-baserade systemet representeras lokal tid på ett indirekt sätt, vilket bland annat medför låg effektförbrukning i förhållande till den precision som uppnås. Oscillatorn driver en räknare, som visar ”råtid”; den ställs aldrig om utan får räkna fritt, och det är inte nödvändigt att frekvensen är extremt stabil eller är styrbar. Servosystemet reglerar alltså varken oscillatorfrekvensen eller den högfrekventa räknarens innehåll. I stället styr det genom att ändra parametrar som används för översättning mellan råtid och den lokala PTP-tiden.

Figur 3 visar att programvaran styr tidsstämplingsmekanismen (”timestamp interface”), att tidsstämplarna skickas upp via en kö till programvaran (varvid mikroprogrammet översätter dem till PTP-tid), och att programvaran har ett ”clock interface”, via vilket det styr parametervärdena. Till höger visas hur en särskild pulstågsfunktion, med hjälp av mikrokod och timersystemet, producerar en konfigurerbar utsignal med flanker vid tidpunkter bestämda av den lokala PTP-tiden, vilket sker via omräkning från PTP- till råtid.

Tidsstämplade meddelanden synkar klockorna Kommunikationen mellan master och slav sker genom utväxling av fem olika meddelandetyper. o Sync: Går från master till slav och tidsstämplas av båda. Det sänds med för applikationen tillräckligt hög frekvens, till exempel varje sekund. o Follow_Up: Går från master till slav och följer omedelbart efter ett Sync och innehåller masterns tidsstämpling för sändandet av Sync-meddelandet. Detta värde subtraherar nu slaven från sin egen tidsstämpel för mottagandet av samma meddelande. Resultatet beror dels av skillnaden mellan klockorna och dels av löptiden från master till slav. Löptiden är ungefär konstant - det händer att det blir extra fördröjning i någon enhet, och det kan hända att det blir en varaktig förändring på grund av omkoppling, men med intelligent filtrering i programvaran kan denna term ses som konstant. Slaven kan därför i en servoloop styra frekvensen hos sin klocka så att skillnaden mellan de två tidsstämplarna håller sig konstant. Storleken på det konstanta värde som skall eftersträvas styrs av en annan automatisk reglering, som beskrivs nedan. o Delay_Req: Detta är ett meddelande som går från slav till master och tidsstämplas av både master och slav. Det sänds normalt med lägre frekvens än Sync-meddelandena. o Delay_Resp: Detta sänds från mastern, som svarsmeddelande på Delay_Req. Det överför masterns tidsstämpling av sin mottagning av Delay_Req. Från detta värde subtraherar nu slaven sin egen tidsstämpel för sändningen. Resultatet beror (jämför ovan) dels av skillnaden mellan klockorna och dels av löptiden från slav till master. Observera att skillnaden mellan klockorna nu kommer in med motsatt tecken mot förut. Om man antar att skillnaden inte ändrat sig sedan senaste Sync, så kan man nu beräkna den verkliga löptiden genom att addera de två skillnaderna och dividera med 2, eftersom de två lika stora termerna tar ut varandra (man förutsätter alltså att löptiden är densamma i båda riktningarna). Även här måste en filtrering ske, på grund av det jitter som uppstår i nätverket. Det filtrerade resultatet använder slaven till att justera sin klockas fas, det vill säga sin lokala ”precisa tid”. När felet här är noll kommer de två skillnaderna mellan tidsstämplar att båda vara lika med löptiden. o Management messages: Dessa är avsedda för underhåll av klockor eller ett system av klockor. En målsättning för standarden är att nätet av klockor inte skall kräva onödig administration, utan i möjligaste mån klara av att konfigurera sig självt automatiskt. De olika noderna måste måste strukturera sina master-slavrelationer på ett sådant sätt att det från varje slav bara finns en väg till ”grandmastern”. Det kan tänkas att det i ett nät finns fler än en klocka som duger som grandmaster, och standarden beskriver hur de då kan förhandla om vem som skall bestämma. Det sker genom en metod som kallas Best Master Algorithm.

Tidsstämpling görs i hårdvara som ligger nära nätverkets fysiska lager. Det begränsar jitter och osäkerhet till enbart de oundvikliga fördröjningarna ute i nätverksförbindelsen mellan master och slav.

Figur 3