IMPLEMENTATION OF A CONFIGURATION SERVER FOR A HARDWARE SNTP
SYNCHRONIZATION PLATFORM BASED ON FPGA
J. Qui os, J. Viejo, A. Millan, A. Mu˜
noz, J. I. Villa and D. Gue e o
G upo ID2 (In es igaci´
on y Desa ollo Digi al)
Depa amen o de Tecnolog´
ıa Elec ´
onica - Uni e sidad de Se illa
E. T. S. Ing. In o m´
a ica, Campus Uni e si a io Reina Me cedes
41012 Se illa (SPAIN)
Email: jqui os@d e.us.es, [email p o ec ed], amilla[email p o ec ed], am i e a@d e.us.es,
[email p o ec ed], gue e@d e.us.es
ABSTRACT
This pape p esen s he implemen a ion o a configu a ion
se e o a SNTP synch oniza ion pla o m which imple-
men s accu a e synch oniza ion solu ions o Remo e Te -
minal Uni s commonly used in indus ial con ol p ocesses.
The configu a ion se e p o ides se ings o o he s pla -
o m de ices using he BOOTP p o ocol and an in e ace
ha allow o adminis e he sys em. This en i onmen e-
qui es a compac (specific dimensions) and low powe and
low cos de ice. Thus, a gene al pu pose de ice (e.g. a PC)
is disca ded and an embedded one wi h hese ea u es has
been de eloped. Howe e , in addi ion o hese equi emen s
i o e s a flexibili y simila o he PC. The eby i is able o
upda e and ca y ou asks beyond synch oniza ion pla o m
easily.
1. INTRODUCTION
The ime synch oniza ion is c i ical in a g ea wide indus-
ial p ocesses. Depending on he applica ion, a p ecision o
up o ew mic oseconds can be equi ed. This p oblem has
been ackled by he indus y, which has de eloped sys ems
o esol e i . Howe e , hese solu ions a e based on so -
wa e and need complex and expensi e ha dwa e o achie e
an accep able accu acy.
In his sense, a synch oniza ion pla o m based on he
indus y no m IEC 61850 [1], which defines he Simple Ne -
wo k Time P o ocol (SNTP) [2] o e E he ne as a s anda d
way o synch onize a se o subs a ions wi h a ime se e ,
has been ully de eloped in ha dwa e, achie ing a low cos
and powe , compac and accu a e pla o m which p o ides
synch oniza ion in he ange o he mic oseconds [3,4].
The SNTP synch oniza ion pla o m consis s o h ee
ypes o de ices: SNTP se e , SNTP clien and configu-
a ion se e (Fig. 1). I can be used in indus ial en i-
onmen s whe e he e a e se e al Remo e Te minal Uni s
��� ��� ���
����
������
����
������
����
������
���� �����
��� ���
���� ����� ���� �����
���� ����� ����
��� ��� ��� ���
��������������� �����������������
������������� �����������������
�������
��������
�������������
������
Fig. 1. Typical scena io o deploying ha dwa e SNTP
clien and se e s (synch oniza ion de ices and p o ocols a e
ma ked in g ay, and configu a ion de ices and p o ocols a e
ma ked in black).
(RTUs) which equi e ime synch oniza ion. The SNTP se -
e ecei es accu acy ime in o ma ion om a Global Po-
si ioning Sys em (GPS) de ice. The SNTP clien s in u n
synch onize wi h he se e h ough Local A ea Ne wo k
(LAN) using he SNTP p o ocol, and ansmi he ime in-
o ma ion o RTUs emula ing a GPS de ice: SNTP clien s
gene a e he GPS signals equi ed, Pulse pe second (PPS)
signal and Recommended Minimum Na iga ion In o ma-
ion (RMC) ame [5,6].
SNTP is a p o ocol o he Applica ion Laye o he TCP/IP
model. The eby a co ec configu a ion o he lowe laye s
(Ne wo k In e ace, In e ne and T anspo ) is necessa y o
a success ul communica ion. Media Access Con ol (MAC)
add ess is assigned and s o ed a bi s eam gene a ion ime
and he NTP s anda d po (123 UDP) is used. Thus, In e -
ne Laye configu a ion is only needed o be configu ed a
ope a ion ime. The configu a ion equi ed by he commu-
nica ion be ween GPS and SNTP se e is he de aul speed
o he se ial po used o ansmi RMC ame and when he
PPS signal indica es he s a o a second: ising o alling
edge. When he SNTP clien emula es he GPS, he s a o
a second is always indica ed by he ising edge o he PPS
signal, so he de aul speed o he se ial po is jus needed.
The e o e, i is necessa y a me hod o configu e all pla -
o m de ices. Because all pla o m de ices a e connec ed
h ough E he ne , Boo s ap P o ocol (BOOTP) will be he
p o ocol used o his pu pose. This unc ionali y is imple-
men ed by he configu a ion se e , which mus ha e he
same ea u es han he pla o m de ices. In his way, he
design can be based on a gene al pu pose de ice (e.g. a PC)
o on a dedica ed one. The fi s is mo e expensi e and highe
powe consume han a dedica ed de ice, u he mo e adap -
ing i o specific dimensions is mo e di ficul han he las
one. The eby, an embedded de ice is he bes op ion, bu a
ully ha dwa e implemen a ion is inflexible: i o en p esen s
long de elopmen and suppo ime and cos . So ha , he
configu a ion se e implemen a ion is based on a Sys em
on Chip (SoC) design which sha e he bes ea u es o he
las wo designs men ioned. On he one hand, i p esen s
a flexibili y simila o a PC: educed de elopmen ime and
cos , i is easily upda ed and e en o being able o ca y ou
unc ionali ies beyond he synch oniza ion pla o m. On he
o he hand, i is an embedded de ice, so i ulfills powe con-
sump ion and size eque imen s. Mo eo e , he cos can be
educed i he de eloped design sha es mos ha dwa e ele-
men s wi h o he pla o m de ices.
This pape desc ibes he configu a ion se e implemen-
a ion and is o ganized as ollows: in sec ion 2 some con-
cep s o BOOTP p o ocol a e p esen ed, sec ion 3 enume -
a es he de ice specifica ions, sec ion 4 gi es some design
and implemen a ion de ails, sec ion 5 includes some esul s,
and sec ion 6 discusses some conclusions.
2. BASIC CONCEPTS OF BOOTP PROTOCOL
The BOOTP is a ne wo k p o ocol based on he clien -se e
model, and i is used by a de ice (clien ) o ob ain i s In e ne
P o ocol (IP) se ings [7]. I s de ailed ope a ion is desc ibed
below (Fig. 2).
When a clien needs IP configu a ion i sends a BOOTP
eques wi h he b oadcas add ess as des ina ion add ess.
This packe is ecei ed and p ocessed by he BOOTP se e ,
which keeps a pool o se ings. I i has an en y o his
clien , which is iden ified wi h i s MAC add ess, he se e
will send a BOOT eply wi h he clien IP se ings. O he -
wise, he se e will no answe (Fig. 2). This p o ocol p o-
����� ������ ����� ���
����������� �������� �� ����
�������������
��� ������������
������ ��������� ����
� ����� �����������������
�� ������� ����� �������
���
����� �������
����� �����
����� ������ ����� ������
��
Fig. 2. Ope a ion o he BOOTP P o ocol.
ides no only IP se ings, he packe o ma includes o he
configu a ion fields [7, 8] as he boo file name used o boo
h ough ne wo k.
His o ically, his p o ocol has been used by de ices a
s a ing up ime o ob ain he needed se ings o connec
a se e and download he Ope a i e Sys em (OS) image
o execu e i . Mo eo e , he BOOTP p o ocol can be used
o ob ain only an IP configu a ion and he eques s can be
sen by a clien any ime. In his way, a dynamic IP add ess
assignmen can be implemen ed sending pe iodic BOOTP
eques s, al hough he p o ocol was designed o p o ide a
s a ic IP add ess assignmen . Nowadays, ano he p o ocol
has limi ed he use o BOOTP: Dynamic Hos Configu a-
ion P o ocol (DHCP) [9]. I o e s mo e unc ionali y han
BOOTP (e.g. dynamic IP add ess assignmen ), bu i s imple-
men a ion is mo e complex. Howe e , DHCP and BOOTP
can be used in he same ne wo k because mos DHCP se e s
a e compa ible wi h BOOTP. In ou pla o m, he SNTP
clien s and se e a e ully implemen ed in ha dwa e, so
he BOOTP is he configu a ion p o ocol chosen because i
educes he complexi y and implemen a ion ime. Fu he -
mo e, i is possible o modi y some aspec s o he p o ocol
o ansmi mo e in o ma ion wi h minimal changes in he
clien s.
3. SYSTEM SPECIFICATION
The objec i e is o de elop a configu a ion se e which
ha e o es ablish wo p ocesses o communica ion. On he
one hand, i will configu e he o he de ices o he pla o m
using he BOOTP p o ocol h ough he LAN. On he o he
hand, i will allow o adminis e he sys em h ough an use
in e ace.
Below a mo e de ailed sys em specifica ion is lis ed:
•The configu a ion se e ha dwa e mus be as simila
as possible o SNTP clien /se e ha dwa e. In his
sense, he same ha dwa e design, which is based on
a SPARTAN-3E XC3S500E FPGA, has been used.
The e o e, i was jus necessa y o add a FLASH me-
mo y (non- ola ile memo y) and a SDRAM memo y
module in o de o achie e a ha dwa e which be able
o un an OS. The eby a mo e flexible, cheape and
easie o assembly ha dwa e is ob ained, due o all
ha dwa e design is eused, adding he needed memo-
ies is conside ed as an assembly op ion, and any pla -
o m de ice can be implemen ed on he se e ha d-
wa e, i is only necessa y o change he design syn he-
sized on FPGA.
•The SoC will be implemen ed on FPGA. An OS will
be execu ed by i o achie e a educ ion in he de el-
opmen and suppo ime.
•The BOOTP p o ocol will be used in he communica-
ion wi h SNTP clien s and se e . So, he se e has
o execu e a BOOTP se e .
•The de ice will adminis e he synch oniza ion pla -
o m h ough a web applica ion. A HTTP se e is
equi ed o his pu pose.
•The implemen ed web applica ion mus ha e he ol-
lowing ea u es:
–I will be based on configu a ion p ofiles.
–I will check and e i y new se ings.
–I will s o e all se ings in a non- ola ile me-
mo y.
•The de ices will be iden ified by i s MAC. The e o e,
he se e has o emembe he MAC o all de ices
ha send a BOOTP eques and has no been config-
u ed p e iously.
•The in e connec ion be ween adminis a ion in e ace
(web applica ion), BOOTP se e and HTTP se e
mus be implemen ed. In ha way, he sys em will be
au onomous.
The de eloped de ice con o ms wi h hese eque imen s
and, in addi ion, i is possible o add new uncionali ies o i .
In he nex sec ions, he de elopmen and he esul s o he
configu a ion se e a e showed.
4. SYSTEM DESIGN AND IMPLEMENTATION
The ha dwa e is based on a SPARTAN-3E XC3S500E FPGA.
The SoC syn hesized on his de ice has been designed wi h
XPS so wa e and i is based on XILINX IP Co es which a e
op imized o be implemen ed on XILINX de ices, so Mi-
c oBlaze is he sys em p ocesso . Pe alinux has been he
chosen embedded Linux dis ibu ion and uClinux [10] he
Linux ke nel.
The se e unc ionali y is implemen ed in so wa e whe-
e is di ided in o h ee modules which a e de ailed below
(Fig. 3).
Adminis a ion in e ace makes up he fi s module. This
communica ion is based on a web applica ion using he HTTP
p o ocol. Thus, he configu a ion in o ma ion is adminis-
e ed h ough a web b owse . Two Common Ga eway In e -
aces (CGIs) ha e been de eloped in C: one o hem (Load
CGI) s a s he p ocess sending he web applica ion and he
cu en sys em configu a ion, and he second one (Apply CGI)
ecei es, checks and applies he modifica ions. All he se -
ings a e checked in he applica ion (clien side) as well.
This las ea u e is implemen ed in Ja aSc ip using he jQue-
y lib a y o achie e a c oss-b owse code. When he new
configu a ion is comple ed, his applica ion sends and se s
i up educing he amoun o FLASH w i ings (in e media e
se ings a e no sa ed). Finally, he h pd web se e has
been he HTTP web se e used.
The second module consis s o he in e ace be ween se -
e and o he s pla o m de ices. The se ings p o ided by
he se e depends on he ype o de ice: SNTP se e o
clien . In e ne Laye configu a ion and de aul speed se ial
o he po a e equi ed by hem bo h. In addi ion o hese
se ings, SNTP se e needs he ac i e edge o he PPS sig-
nal, and he SNTP clien needs he SNTP se e IP add ess
and he in e al ime be ween SNTP eques s. The BOOTP
p o ocol is used o his pu pose. The packe o ma defined
by his p o ocol has fields o ansmi In e ne Laye configu-
a ion (IP add ess, ne mask, and de aul ga eway), bu i do
no ha e fields o pla o m specific in o ma ion. Howe e ,
his se ings a e send in he boo file name field. The se ings
a e ansmi ed as a s ing o hexadecimal digi s codified as
ASCII cha ac e s which will be di e en depending on he
ype o de ice. This me hod only modifies he seman ic o
a field p oducing alid BOOTP packe s. So he se e can
ope a e wi h s anda d BOOTP clien s. The In e ne Sys ems
Conso ium (ISC) DHCP so wa e, which is a DHCP and
BOOTP se e , is he BOOTP se e used.
Finally, he hi d module defines he in e connec ion be-
ween he wo in e aces p e iously desc ibed (Fig. 3). In
his sense, web applica ion mus be able o ead and modi y
he cu en se ings, which a e used by he BOOTP se e o
configu e he pla o m de ices. These se ings a e sa ed in
he BOOTP se e configu a ion file, which is loca ed on he
non- ola ile memo y. A s a ing up ime, he se e checks
and e ifies his file o insu e he sys em ope a ion. The
unc ionali y o showing he cu en configu a ion is imple-
men ed by he Load CGI, which eads and pa ses his file.
When he web applica ion sends new se ings o be sa ed
���� ������������
���� ������������
���� �������
���� �������
�����
��� ������
�������� ����� ���
����� ������
����� ������
������������������
����
�����������
����� �������
��������
�������������
����� �����
���
��
������������� ����� ��� ��������
������ � ������ � ������ �
Fig. 3. O e all diag am o he configu a ion se e ope a ion.
and applied, Apply CGI checks he alidi y and cohe ence
o he new configu a ion and hen gene a es he new BOOTP
se e configu a ion file. Mo eo e , he se e mus sa e all
add esses o pla o m de ices, because he de ices a e iden-
ified wi h i s MAC add ess. In his way, he MAC o he
known de ices a e loca ed in he BOOTP se e configu a-
ion file. I an unknown de ice sends a BOOTP eques i s
add ess has o be sa ed. The BOOTP se e has been con-
figu ed o send log in o ma ion o syslog daemon, which in
u n w i es his in o ma ion o a log file. Load CGI eads and
pa ses his file o show unknown de ices add esses. Fu he -
mo e, he sys em shows he ela i e and absolu e da e and
ime o he fi s BOOTP eques o each de ice.
5. RESULTS
In his sec ion, ha dwa e and so wa e implemen a ion e-
sul s a e desc ibed in some de ail.
Resou ce Usage (%)
Slices 4238 (91%)
Slices Flip Flops 4958 (53%)
4 Inpu LUTs 7444 (79%)
Bonded IOBs 75 (47%)
Block RAMs 19 (95%)
GCLKs 6(25%)
Maximum ope a ion equency 75.857 MHz
Table 1. Ha dwa e implemen a ion esul s on SPARTAN-3E
XC3S500E.
5.1. Ha dwa e esul s
The SoC design has been implemen ed on a SPARTAN-3E
XC3S500E FPGA. The Table 1 shows he design esul s.
The maximum ope a ion equency (75 MHz) is enough,
due o i is o e PCB clock equency (50 MHz). I is e-
ma kable ha 95% o Block RAMs a e used by he design.
The e o e, he Memo y Managemen Uni (MMU) suppo
in Mic oBlaze P ocesso can no be used, due o he ac
Usage o RAM memo y
To al usage o RAM memo y
I em Maximum memo y usage in KB (%)
To al Memo y 28900 (100%)
Wa ing a BOOTP/HTTP eques 11344 (39.25%)
Maximum load (Sa ing se ings) 11628.28 (40.24%)
Usage o RAM memo y by p ocesses
P ocess Maximum memo y usage in KB (%)
BOOTP se e 578.336 (2.00%)
HTTP se e 292.916 (1.01%)
Load CGI 141.492 (0.49%)
Sa e GCI 271.248 (0.94%)
To al 1283.992 (4.44%)
Usage o FLASH memo y
Usage o FLASH memo y
I em Memo y usage in KB (%)
To al Memo y 15625 (100%)
Sys em loade 800 (5.12%)
Ope a i e Sys em 4000 (25.6%)
Use Flash pa i ion 8000 (51.2%)
To al 12800 (81.92%)
Table 2. Usage o RAM and FLASH memo y.
����
������ �
����
������ �
����
������ �
����
������ � ������
�������������
������
����
������
�������
�������� ���
Fig. 4. En i onmen used o es he configu a ion se e .
ha ou addi ional Block RAMs a e equi ed o his pu -
pose. Fo his eason a non-MMU suppo Linux Ke nel
(uClinux) has been used. This is because he se e ha d-
wa e should be as simila as possible o ha dwa e o o he
pla o m de ices, and a low cos FPGA is used by hem. I
he immedia ely abo e de ice in he Spa an-3E amily is
chosen, he Mic oBlaze P ocesso wi h MMU suppo may
be syn hesized and a ull Linux ke nel (wi h MMU suppo )
may be used. Mo eo e , he usage o Slices will be below
50% and i would be possible o syn hesize o he ha dwa e
unc ionali ies on he same de ice.
5.2. So wa e esul s
The en i onmen whe e he es s ook place is showed by
Fig. 4, whe e all de ices we e u ned on and he se ings
we e modified along he ime o check s abili y, possible e -
o s and memo y usage o he sys em. Fig. 5 shows he web
in e ace o he configu a ion se e . The CPU esul s a e
no ele an because he configu a ion p ocess is no a c i -
ical ask, so hey a e omi ed. Rega ding o RAM memo y
usage (Table 2), i is ema kable ha mo e han 50% o he
a ailable memo y is ee. This ac allows o add new so -
wa e implemen ed unc ionali ies o he sys em. The 82%
o FLASH memo y is used by he sys em (Table 2). How-
e e , he use FLASH pa i ion size can be educed i mo e
FLASH memo y is equi ed by he OS image. Se ings o
a new de ice equi e ≈99 by es and o a new configu a-
ion p ofile ≈64 by es. The eby, i pa i ion size is educed
by hal , he sys em can con inue wo king, bu a fi size can
educe he FLASH li e.
6. CONCLUSION
The design and implemen a ion o a configu a ion se e o
he SNTP synch oniza ion pla o m has been p esen ed. I
has been based on a SoC syn hesized on a FPGA, which exe-
cu es an OS. The unc ionali y is implemen ed in so wa e o
achie e a flexible, low powe and low cos and compac de-
ice ha i is no limi ed o he pla o m en i onmen being
able o ca y ou asks beyond i .

Fig. 5. Web in e ace o he configu a ion se e .
7. ACKNOWLEDGMENT
This wo k has been pa ially suppo ed by he Minis y o
Educa ion and Cul u e o he Spanish Go e nmen h ough
he TEC2007-61802/MIC (HIPER) p ojec and he PROFIT-
MITC SEPIC TSI-020100-2008-258 p ojec .
8. REFERENCES
[1] H. Dawidczak, “IEC 61850 Communica ion Ne wo ks and
Sys ems In Subs a ions,” In e na ional Elec o echnical Com-
mission and Technical Commi ee 57, 1995.
[2] D. Mills, “Simple Ne wo k Time P o ocol (SNTP) Ve sion
4 o IP 4, IP 6 and OSI,” In e ne Enginee ing Task Fo ce
(IETF), RFC 4330 (In o ma ional), Jan. 2006.
[3] J. Viejo, J. Juan, M. J. Bellido, E. Os ua, A. Millan, P. R.
de Cla ijo, A. Mu˜
noz, and D. Gue e o, “Design and imple-
men a ion o a SNTP clien on FPGA,” in P oc. 2008 IEEE
In e na ional Symposium on Indus ial Elec onics (ISIE),
Camb idge (Uni ed Kingdom), July 2008.
[4] J. Viejo, J. Juan, E. Os ua, M. J. Bellido, A. Millan,
A. Mu˜
noz, and J. I. Villa , “Accu a e and compac implemen-
a ion o a ha dwa e SNTP Clien ,” in P oc. 15 h Ibe chip
Wo kshop (IWS), Buenos Ai es (A gen ina), Ma . 2009.
[5] J. Qui os, J. Viejo, A. Mu˜
noz, A. Millan, E. Os ua, and J. I.
Villa , “Implemen aci´
on sob e FPGA de un clien e SNTP us-
ando Mic oBlaze,” in P oc. 16 h Ibe chip Wo kshop (IWS),
Iguazu Falls (B azil), Feb. 2010.
[6] E. Os ua, M. J. Bellido, J. Viejo, A. Millan, A. Mu˜
noz,
and D. Gue e o, “Aplicaci´
on de Picoblaze como Emu-
lado /Recep o de un GPS en el dise˜
no ha dwa e de un
clien e/se ido SNTP,” in 9 h Jo nadas de Compu aci´
on Re-
configu able y Aplicaciones (JCRA), Mad id (Spain), Sep .
2009.
[7] W. J. C o and J. Gilmo e, “Boo s ap P o ocol,” In e ne
Enginee ing Task Fo ce (IETF), RFC 951 (D a S anda d),
Sep . 1985, upda ed by RFCs 1395, 1497, 1532, 1542.
[8] R. D oms and S. Alexande , “DHCP Op ions and BOOTP
Vendo Ex ensions,” In e ne Enginee ing Task Fo ce (IETF),
RFC 2132 (S anda ds T ack), Ma . 1997.
[9] ——, “Dynamic Hos Configu a ion P o ocol,” In e ne En-
ginee ing Task Fo ce (IETF), RFC 2131 (DRAFT STAN-
DARD), Ma . 1997.
[10] R. Klenke, “Expe iences using he xilinx mic oblaze so -
co e p ocesso and uclinux in compu e enginee ing caps one
senio design p ojec s,” in Mic oelec onic Sys ems Educa-
ion, 2007. MSE ’07. IEEE In e na ional Con e ence on, June
2007, pp. 123 – 124.