Architecture SoC/SoPC pour les applications réseaux nécessitant des fonctions de parsing
Bertrand LE GAL
[bertrand.legal@ims-bordeaux.fr]
Laboratoire IMS - UMR CNRS 5218 ENSEIRB-MATMECA, Bordeaux INP
Université de Bordeaux Talence, France
18 / 11 / 2015
31.05.2010
1/2
L"Université de Bordeaux publie une étude comparative des initiatives campus verts menées à l"échelon international, qui représente une source précieuse d"informations et de réflexions pour l"élaboration de son nouveau modèle d"Université dans le cadre de l"Opération campus. Elle fait le choix de diffuser en accès libre cette étude, le développement durable étant l"affaire de tous et pour l"intérêt de tous.
L*Université de Bordeaux s*est engagée à bâtir un nouveau modèle d*Université, et parallèlement à de- venir leader en matière de développement durable. C*est en ce sens que début 2009, elle a répondu favorablement, conjointement avec l*Université Bordeaux 1 Sciences Technologies, à la proposition d*Ecocampus-Nobatek et d*EDF : réaliser un retour d*expériences et des analyses sur des projets campus verts en France, Europe et Amérique du Nord.
L*objectif de cette étude (cf. page suivante) a été d*observer et de capturer les bonnes pratiques et ac- tions exemplaires relatives aux grands piliers du développement durable : domaines économiques, so- ciaux, environnementaux et organisationnels. L*Université de Bordeaux va s*y référer pour mettre en Wuvre une gouvernance et une stratégie à long terme au service d*un campus plus vivable et plus équi- table pour l*ensemble de la communauté universitaire.
Avec le Grenelle de l*environnement comme repère à atteindre puis à dépasser, l*Université de Bor- deaux entend constituer un site pilote à travers une démarche de développement durable globale par : - l*intégration permanente des dimensions humaines dans le projet immobilier et l*aménagement (acces- sibilité, santé, lisibilité, confort, cadre de vie) ;
- une transformation énergétique radicale des bâtiments dans le cadre de leur rénovation en démarche HQE® et un schéma directeur énergétique pour une réduction maximale des gaz à effet de serre ; - la mise en valeur et la sanctuarisation d*un parc sur le site universitaire de Talence-Pessac- Gradignan, véritable poumon vert à l*échelle de l*agglomération, atout exceptionnel pour la qualité de vie des usagers et le développement de la biodiversité en milieu urbain ;
- un plan de déplacement sur l*ensemble des domaines du campus universitaire, afin de réduire l*usage individuel de la voiture et son impact en s*appuyant sur des réseaux de transports en commun perfor- mants et le développement des modes alternatifs ;
- une ouverture concertée sur la ville, visant à favoriser le développement économique des territoires, celui de la vie de campus et à créer une mixité sociale et fonctionnelle ;
- et enfin, condition sine qua non de réussite, la mise en place d*un processus d*information et de concer- tation auprès de tous les membres et acteurs de l*Université, pour une compréhension partagée des en- jeux et un apprentissage des comportements responsables.
Aussi, l*Université de Bordeaux entend-elle élaborer un agenda 21 et faire de son campus un site d*expérimentation permettant de développer des approches innovantes à partir des compétences des laboratoires.
L*étude « Initiatives campus verts » est téléchargeable sur le site www.univ-bordeaux.fr
Contacts presse Université de Bordeaux
Anne SEYRAFIAN . Norbert LOUSTAUNAU . T 33 (0)5 56 33 80 84 . communication@univ-bordeaux.fr Contact Nobatek-Ecocampus
Julie CREPIN, chef de projet . T 33 (0)5 56 84 63 72 . jcrepin@nobatek.com
L*Université de Bordeaux
Vers un nouveau modèle d"Université DURABLE
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Plan de la présentation
1. Introduction
2. L’analyse protocolaire ?
3. Les approches usuelles
4. La plateforme développée
5. Evaluation de la plateforme
6. La flexibilité du système
7. Conclusion
2
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les partenaires du projet de recherche (1/3)
3
Vue aérienne partielle du campus Bordelais
(anciennement Université de Bordeaux 1)
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les partenaires du projet de recherche (2/3)
4
Section CNU 27
Section CNU 63
Section
CNU 61
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les différents acteurs du projet de recherche (3/3)
5
Laurent Réveillère David Bromberg Bertrand LE GAL
Julien Bézine Julien Marcadal Jigar Solanski
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Contexte de l’étude
6
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les systèmes communicants dans le monde moderne
๏ Omniprésence des systèmes embarqués communicants
depuis le début des années 2k,
- Augmentation de leur nombre;
- Augmentation de leur hétérogénéité.
๏ Apparition de nouvelles
problématiques de conception:
- Consommation d’énergie;
- Coût de production (silicium);
- « Time to market »;
- Performance (débit, latence).
๏ Problématiques liées à la
communication (couche haute).
7
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les systèmes communicants dans le monde moderne
๏ L’Internet of Things (IoT) accroit cette problématique:
- Les systèmes sont hétérogènes (chipset, uProc, etc.);
- Les systèmes sont hétérogènes (couches logicielles, OS);
๏ Eco-systèmes divergents:
- Constructeurs différents poussant des éco-systèmes non compatibles;
๏ Besoin de développer des protocoles « génériques »:
- Basés sur des standards
(interopérabilité, « human readable »);
- Dvpt de passerelles protocolaires.
8
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les protocoles de communication de niveau applicatif (1/2)
9
Format ad-hoc « binaire »
Les messages sont codés via un protocol dédié (binaire) => efficacité
Plantogène lors du développement Peu évolutif dans le temps
Pas ou peu interopérabilité
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les protocoles de communication de niveau applicatif (2/2)
10
Message textuel (ad-hoc, standard based) Human readable, mise au point facilitée Réutilisation possible de parsers existants
<ID>ID=TOTO; PWD=TrUc</ID>
<ANSW>OK</ANSW>
Moins efficace (octets/message)
Analyseur logiciel plus complexe
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
L’analyse protocolaire expliquée à l’aide du protocole HTTP
11
https://www3.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html
Analyse coté « serveur »
Exemples de réponses à analyser coté « client »
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Cas d’étude appliqué à l’enregistrement dans le protocole SIPS
12
Bob SIP Server | | | REGISTER F1 | |--->|
| 401 Unauthorized F2 | |<---|
| REGISTER F3 | |--->|
| 200 OK F4 | |<---|
| |
F1 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS client.biloxi.example.com:5061;
Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 1 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Content-Length: 0
RFC 3665
SIP Basic Call Flow Examples December 2003
http://tools.ietf.org/html/rfc3665#page-5
F2 401 Unauthorized SIP Server -> Bob
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashds7 ;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=a73kszlfl To: Bob <sips:bob@biloxi.example.com>;tag=1410948204 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="atlanta.example.com", qop="auth", nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5 Content-Length: 0
F3 REGISTER Bob -> SIP Server
REGISTER sips:ss2.biloxi.example.com SIP/2.0
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 Max-Forwards: 70
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH To: Bob <sips:bob@biloxi.example.com>
Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>
Authorization: Digest username="bob", realm="atlanta.example.com"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="", uri="sips:ss2.biloxi.example.com",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
F4 200 OK SIP Server -> Bob
SIP/2.0 200 OK
Via: SIP/2.0/TLS client.biloxi.example.com:5061;branch=z9hG4bKnashd92 ;received=192.0.2.201
From: Bob <sips:bob@biloxi.example.com>;tag=ja743ks76zlflH To: Bob <sips:bob@biloxi.example.com>;tag=37GkEhwl6 Call-ID: 1j9FpLxk3uxtm8tn@biloxi.example.com
CSeq: 2 REGISTER
Contact: <sips:bob@client.biloxi.example.com>;expires=3600 Content-Length: 0
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
What are text-based message protocols ?
13
VLC player GET the_video FORMAT mp4, avi, mpg
OK FORMAT mp4 LENGTH 37826 BODY ... ...
Protocols can be standardized or application dedicated
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Quelques exemples de protocoles couramment employés
14
Multimédia (streaming)
Internet (HTTP)
E-Mail (SMTP)
Transfert (FTP)
Chat (MSN, Jabber)
Annuaire (LDAP)
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
L’analyse protocolaire dans les systèmes embarqués
15
๏ Les systèmes communicants
peuvent être embarqués, mobiles et contraints en énergie.
๏ En fonction de leurs roles, ils peuvent avoir:
- Un protocole à supporter;
- Peu de protocoles à supporter (passerelle, concentrateur).
๏ Les contraintes de performance:
- Consommation d’énergie;
- Cout de production (silicium);
- Performance (débit, latence).
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
L’analyse protocolaire dans les systèmes HPC
16
๏ Des besoins de communication analogues se situent du coté des
« serveurs de données »,
- type ordinateur de bureau gérant de multiples périphériques;
- type ferme de calcul (Web serveur);
๏ Les problématiques de conception divergent:
- Performance (latence, débit);
- Consommation d’énergie (dissipation);
- Flexibilité (nombre de protocoles, mise à jour des spécifications);
- Réutilisabilité entre différents projets.
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Techniques de communication, positionnement des travaux
๏ L’étude s’est focalisée sur la couche applicative du modèle OSI.
๏ Un middleware est
généralement en charge du support protocolaire:
- Lecture et analyse des messages entrants;
- Génération des messages sortants.
๏ Dissociation entre le protocole de communication et
l’application,
- Meilleure ré-utilisabilité.
17
Processing layers
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Le processus d’analyse protocolaire
18
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
I/O of the message-parsing process
19
12:6 B. Le Gal et al.
%%{
machine foo parser;
SP = ’ ’;
main := ’USER’ SP ’LOGIN’ ’=’ alnum+ ^login SP ’PASS’ ’=’ alnum+
^pass SP ’END’ ^^; }%%
Fig. 3. Specification of the message protocol for automatic software generation
codes are automatically generated. An example of application source code using gen- erated code is provided in Fig. 4.
Implementation of protocol parsers may require complex automata from dozens to hundreds of states as shown in Section 5.
4. PROPOSED APPROACH 4.1. Introduction
A well-known approach to implement an embedded application in a SoC is to develop a fully dedicated architecture, for Application-specific Integrated Circuits (ASICs) or Field Programmable Gate Array (FPGA) devices. However, dedicated hardware de- sign has important drawbacks. Indeed, it is a tedious and time-consuming process compared to traditional software development. Moreover, dedicated design efficiency is characterized by low flexibility: modifying system specifications may require time- consuming modifications or redevelopment processes. This characteristic discards this solution from network application domain where applications required flexibility and programmability. To alleviate the burden in hardware-based implementations and in- crease design flexibility, the codesign methodology proposes to slice an application based on performances it requires. Parts of the application that requires high perfor- mance are implemented using dedicated hardware units. Less sensitive performance parts (or parts requiring flexibility or programmability) are implemented as software code running over aGeneral-Purpose Processor (GPP). Message parsing task is mainly decomposed in two mains parts: (i) the automata implementation (transition evalu- ation and next state computation); (ii) the callback functions invoked when the au- tomata has detected a pattern or an error in the analysed data stream.
A profiling evaluation of real-life parsers (such as those used in HTTP or SIP based applications) on network captured data streams shows that most of the execution time (> 90%) is spent in the automata processing. Indeed, execution time of callback func- tions (that fill the software view are only executed when patterns are detected) is negli- gible. According to these profiling results, we decided to speed-up the message parsing execution using a hardware-based implementation for the automata processing. Call- back functions are left in software for flexibility reasons. Indeed, depending on the
// create the data structure authentification msg dataSet;
// read data from network socket
int nb data = read(socket, buffer, BUFFER SIZE);
// process the data stream
parser stream(dataSet, buffer, nb data);
// print the parsed values on screen
printf("connection from %s [%s]\n", get user(dataSet), get passwd(dataSet);
Fig. 4. Network parsing application
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
High-level protocol description
A flexible SoC and its methodology... 12:5
USER LOGIN=UserLambda PASS=*its-p@SsW0rd! END
Fig. 1. Text message example 2.3. Conclusion
To the best of our knowledge, previous work on hardware support for network protocol message processing has been mainly limited to XML parsing and pattern recognition using regular expressions and do not cover network message parsing requirements.
To provide at the same time performance and software flexibility, we present in this article a codesign-based system specialized for message parsing tasks. An automated methodology has been developed to allow: (i) automatic accelerator generation from protocol specification, (ii) automatic SoC adaptation to support the generated cores, (iii) software code generation to enable seamless usage of coprocessor from the network application. This architecture and the associated design flow, generated system can be used by network software developers without any hardware knowledge requirements.
3. AN ILLUSTRATIVE CASE STUDY
To ease the development of communicating applications, many of the commonly used protocols are composed of messages that can be directly read by humans. However standard text-based protocol message parsers consumes up to 25% of the execution time of usual network applications. This runtime comes from the message analysis task that extracts the relevant information to generate a software view for the applica- tion layer. Let’s consider the text message provided in Fig. 1. This text-based message contains the username and its associated password.
The message parsing task consists in extracting valuable information (e.g. login and password fields) from the data stream and to fill asoftware view- such as a data struc- ture - within the extracted information (e.g. Fig. 2). The second parser task consists in validating the syntax e.g. first, the login can contain upper and/or lower case charac- ters and digits but no space or special characters; secondly the message stream starts by the USER keyword, finishes by the END keyword, the valuable content is located between these two patterns. Moreover, information order is checked: the LOGIN field is provided before the PASS one.
To speed-up message parser development, automated flows were developed e.g.
[Burgy et al. 2011; Stefanec and Skuliber 2011]. They generate software implemen- tation of parsers from a high-level specification of the message protocol to analyse (i.e.
network protocol specifications). An example of such high-level specification of the pro- tocol is provided in Fig. 3. Protocol specification provided corresponds to the example provided in Fig. 1. According to the protocol specification, it is possible to generates:
(i) the software implementation of message parser; (ii) the data structure required to store the revelant information (Fig. 2); (iii) a set of specialized functions for accessing (filling/reading) the information contain in data structure.
This software code set enables software developers to integrate message-parsing ca- pabilities in their applications in a seamless fashion. Indeed, parser related source
struct authentification msg{ char username[64];
// contains UserLambda after the Fig. 1 message parsing char password[64];
// contains *its p@SsW0rd! after the Fig. 1 message parsing };
Fig. 2. Example of software view
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
Textual message sample
12:6 B. Le Gal et al.
%%{
machine foo parser;
SP= ’ ’;
main := ’USER’ SP ’LOGIN’ ’=’ alnum+ ^login SP ’PASS’ ’=’alnum+
^pass SP ’END’ ^^;
}%%
Fig. 3. Specification of the message protocol for automatic software generation
codes are automatically generated. An example of application source code using gen- erated code is provided in Fig. 4.
Implementation of protocol parsers may require complex automata from dozens to hundreds of states as shown in Section 5.
4. PROPOSED APPROACH 4.1. Introduction
A well-known approach to implement an embedded application in a SoC is to develop a fully dedicated architecture, for Application-specific Integrated Circuits (ASICs) or Field Programmable Gate Array (FPGA) devices. However, dedicated hardware de- sign has important drawbacks. Indeed, it is a tedious and time-consuming process compared to traditional software development. Moreover, dedicated design efficiency is characterized by low flexibility: modifying system specifications may require time- consuming modifications or redevelopment processes. This characteristic discards this solution from network application domain where applications required flexibility and programmability. To alleviate the burden in hardware-based implementations and in- crease design flexibility, the codesign methodology proposes to slice an application based on performances it requires. Parts of the application that requires high perfor- mance are implemented using dedicated hardware units. Less sensitive performance parts (or parts requiring flexibility or programmability) are implemented as software code running over aGeneral-Purpose Processor (GPP). Message parsing task is mainly decomposed in two mains parts: (i) the automata implementation (transition evalu- ation and next state computation); (ii) the callback functions invoked when the au- tomata has detected a pattern or an error in the analysed data stream.
A profiling evaluation of real-life parsers (such as those used in HTTP or SIP based applications) on network captured data streams shows that most of the execution time (> 90%) is spent in the automata processing. Indeed, execution time of callback func- tions (that fill the software view are only executed when patterns are detected) is negli- gible. According to these profiling results, we decided to speed-up the message parsing execution using a hardware-based implementation for the automata processing. Call- back functions are left in software for flexibility reasons. Indeed, depending on the
// create the data structure authentification msg dataSet;
// read data from network socket
int nb data = read(socket, buffer, BUFFER SIZE);
// process the data stream
parser stream(dataSet, buffer, nb data);
// print the parsed values on screen
printf("connection from %s [%s]\n", get user(dataSet),get passwd(dataSet);
Fig. 4. Network parsing application
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
Pedagogical application
A flexible SoC and its methodology... 12:5
USER LOGIN=UserLambda PASS=*its-p@SsW0rd! END
Fig. 1. Text message example 2.3. Conclusion
To the best of our knowledge, previous work on hardware support for network protocol message processing has been mainly limited to XML parsing and pattern recognition using regular expressions and do not cover network message parsing requirements.
To provide at the same time performance and software flexibility, we present in this article a codesign-based system specialized for message parsing tasks. An automated methodology has been developed to allow: (i) automatic accelerator generation from protocol specification, (ii) automatic SoC adaptation to support the generated cores, (iii) software code generation to enable seamless usage of coprocessor from the network application. This architecture and the associated design flow, generated system can be used by network software developers without any hardware knowledge requirements.
3. AN ILLUSTRATIVE CASE STUDY
To ease the development of communicating applications, many of the commonly used protocols are composed of messages that can be directly read by humans. However standard text-based protocol message parsers consumes up to 25% of the execution time of usual network applications. This runtime comes from the message analysis task that extracts the relevant information to generate a software view for the applica- tion layer. Let’s consider the text message provided in Fig. 1. This text-based message contains the username and its associated password.
The message parsing task consists in extracting valuable information (e.g. login and password fields) from the data stream and to fill asoftware view- such as a data struc- ture - within the extracted information (e.g. Fig. 2). The second parser task consists in validating the syntax e.g. first, the login can contain upper and/or lower case charac- ters and digits but no space or special characters; secondly the message stream starts by the USER keyword, finishes by the END keyword, the valuable content is located between these two patterns. Moreover, information order is checked: the LOGIN field is provided before the PASS one.
To speed-up message parser development, automated flows were developed e.g.
[Burgy et al. 2011; Stefanec and Skuliber 2011]. They generate software implemen- tation of parsers from a high-level specification of the message protocol to analyse (i.e.
network protocol specifications). An example of such high-level specification of the pro- tocol is provided in Fig. 3. Protocol specification provided corresponds to the example provided in Fig. 1. According to the protocol specification, it is possible to generates:
(i) the software implementation of message parser; (ii) the data structure required to store the revelant information (Fig. 2); (iii) a set of specialized functions for accessing (filling/reading) the information contain in data structure.
This software code set enables software developers to integrate message-parsing ca- pabilities in their applications in a seamless fashion. Indeed, parser related source
struct authentification msg{
char username[64];
// contains UserLambda after the Fig. 1 message parsing char password[64];
// contains *its p@SsW0rd! after the Fig. 1 message parsing };
Fig. 2. Example of software view
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
Internal message view
functions for message view
management
Automaton for message
analysis
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Automata-based parsing process
20
A flexible SoC and its methodology... 12:5
USER LOGIN=UserLambda PASS=*its-p@SsW0rd! END
Fig. 1. Text message example
2.3. Conclusion
To the best of our knowledge, previous work on hardware support for network protocol message processing has been mainly limited to XML parsing and pattern recognition using regular expressions and do not cover network message parsing requirements.
To provide at the same time performance and software flexibility, we present in this article a codesign-based system specialized for message parsing tasks. An automated methodology has been developed to allow: (i) automatic accelerator generation from protocol specification, (ii) automatic SoC adaptation to support the generated cores, (iii) software code generation to enable seamless usage of coprocessor from the network application. This architecture and the associated design flow, generated system can be used by network software developers without any hardware knowledge requirements.
3. AN ILLUSTRATIVE CASE STUDY
To ease the development of communicating applications, many of the commonly used protocols are composed of messages that can be directly read by humans. However standard text-based protocol message parsers consumes up to 25% of the execution time of usual network applications. This runtime comes from the message analysis task that extracts the relevant information to generate a software view for the applica- tion layer. Let’s consider the text message provided in Fig. 1. This text-based message contains the username and its associated password.
The message parsing task consists in extracting valuable information (e.g. login and password fields) from the data stream and to fill a software view - such as a data struc- ture - within the extracted information (e.g. Fig. 2). The second parser task consists in validating the syntax e.g. first, the login can contain upper and/or lower case charac- ters and digits but no space or special characters; secondly the message stream starts by the USER keyword, finishes by the END keyword, the valuable content is located between these two patterns. Moreover, information order is checked: the LOGIN field is provided before the PASS one.
To speed-up message parser development, automated flows were developed e.g.
[Burgy et al. 2011; Stefanec and Skuliber 2011]. They generate software implemen- tation of parsers from a high-level specification of the message protocol to analyse (i.e.
network protocol specifications). An example of such high-level specification of the pro- tocol is provided in Fig. 3. Protocol specification provided corresponds to the example provided in Fig. 1. According to the protocol specification, it is possible to generates:
(i) the software implementation of message parser; (ii) the data structure required to store the revelant information (Fig. 2); (iii) a set of specialized functions for accessing (filling/reading) the information contain in data structure.
This software code set enables software developers to integrate message-parsing ca- pabilities in their applications in a seamless fashion. Indeed, parser related source
struct authentification msg { char username[64];
// contains UserLambda after the Fig. 1 message parsing char password[64];
// contains *its p@SsW0rd! after the Fig. 1 message parsing } ;
Fig. 2. Example of software view
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
void UserStart(
struct* p_auth, struct* m_view , char* stream, int c_pos )
{
p_auth.start_user = c_pos;
} void UserStop(
struct* p_auth, struct* m_view, char* stream, int c_pos )
{
int firstC = p_auth.start_user;
int length = c_pos - p_auth.start_user;
if( length > 64 ) { printf(« oups »); exit( -1 ); }
memcpy(m_view->username, &stream[firstC], length);
}
4 'L' 5 6 7 8 9 A
0
'O' 'G' 'I' 'N' '='
E
B not ' ' ' '
C D
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
C’est un problème (trop) simple…
augmentons donc un peu le challenge ;-(
21
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
The Christmas wish list network application developers
22
Many message protocols Design flow (fast/flexible)
Low-latency and high-throughput Low-cost Low-power
Many streams in parallel
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
The « funny » hazards in network-based applications
23
P1 - 1/2 P1 - 2/2 P2 - 1/2 P2 - 2/2
P3 - 1/2 P3 - 2/2 P1 - 1/2 P1 - 2/2 P2 - 1/2 P2 - 2/2 P3 - 1/2 P3 - 2/2 1. Sequential use case - N users and N different protocols
P1 - 1/2 P1 - 2/2 P2 - 1/2 P2 - 2/2
P3 - 1/2 P3 - 2/2 P1 - 1/2 P2 - 1/2 P3 - 1/2 P1 - 2/2 P2 - 2/2 P3 - 2/2 2. Interleaved use case - N users and N different protocols
P1 - 1/2 P1 - 2/2 P1 - 1/2 P1 - 2/2
P1 - 1/2 P1 - 2/2 P1 - 1/2 P1 - 1/2 P1 - 1/2 P1 - 2/2 P1 - 2/2 P1 - 2/2 3. Interleaved use case - N users and only one protocol
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Related works
24
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Methodologies actuelles de développement (1/2)
25
Application binary
Network application specification
handwriting
Legacy parser Application
logic
reusing
Code compilation
General Purpose Processor
Application binary
Network application specification
handwriting
Parser specifications Application
logic
Code compilation
General Purpose Processor Generator Dedicated software parser
Manual task for the network application developper Automated task for the network application developper Targetted embedded system
(a) Methodology based on legacy
parser reusing (b) Methodology based on
dedicated software parser
<== Tim e co nsu m in g == === Fu lfill need s ? ==>
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Methodologies actuelles de développement (2/2)
26
Application binary
Network application specification
handwriting
Legacy parser Application
logic
reusing
Code compilation
General Purpose Processor
Application binary
Network application specification
handwriting
Parser specifications Application
logic
Code compilation
General Purpose Processor Generator Dedicated software parser
Manual task for the network application developper Automated task for the network application developper Targetted embedded system
(a) Methodology based on legacy
parser reusing (b) Methodology based on
dedicated software parser
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Automatic generation of software parsers (Zebu, Ragel)
27
C/C++
compiler
General Purpose Processor Automate
réalisant l’analyse protocolaire
Ou9l d’analyse et de généra9on de
codes logiciels Spécifica9ons «textuelles»
Spécifica9ons formelles
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Automatic generation of software parsers (Zebu, Ragel)
28
Applica'on source code
C/C++
compiler
Code logiciel construit à base de GOTO.
Caractéris9ques:
- Forte emprunte mémoire - Rapidité d’exécu9on
General Purpose Processor Applica'on
source code
Code logiciel construit à base de Tableau (indexa9on).
Caractéris9ques:
- Faible emprunte mémoire - Lenteur à l’exécu9on
(calculs dichotomiques)
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Solution conjointe envisagée (processeur + coprocesseurs)
29
A flexible SoC and its methodology... 12:7
Hardware Accelerator (Parser)
"GET HTTP/1.1 …"
<action=31, pos=0>
<action=26, pos=2>
<action=??, pos=?>
General Purpose Processor Ethernet
controler
Harddrive
Fig. 5. Proposed approach for protocol parsing application speed-up, composed of a General Purpose Pro- cessor and a hardware accelerator
network application requirements, they can perform processing like string to integer conversion or memory copy that are efficiently implemented in software.
An overview of the proposed sharing out is provided in Fig. 5. The GPP, that ex- ecutes the application, provides the data stream to the coprocessor. The coprocessor analyses the message characters and returns the processing results to the processor.
The results are provided as a set (callback function identifier, stream position). The processor uses this information set to fill the software view. The processor invokes the callback function with the position of the character that generates this action.
A description of the different hardware and software layers involved in the system is provided in Fig. 6. Software applications requiring message-parsing capabilities do not access directly the accelerators neither the low-level API. Processing executions over accelerators are managed by the Hardware Abstraction Layer (HAL). This layer focuses on identification of accelerators and parallel processing management (sharing hardware units between multiple threads). Moreover, this approach provides a seam- less access to the protocol parsers independently of its implementation, its connectivity and the system context. Driver layer provides abstract coprocessor access API through low-level functions. This software and hardware stack enables an easy programming approach of the proposed SoC architecture.
4.2. Design methodology
Designing a coprocessor unit from protocol specifications, integrating coprocessor and finally writing software code are long and complex tasks. Moreover, these tasks require deep knowledge in hardware design, software development and network protocols. To enable the development of efficient dedicated systems compatible with time to market constraint, an automated flow was elaborated. This methodology removes the need for developer intervention in the complex process of developing and using a coprocessor in a software application. Proposed design methodology is presented in Fig. 7.
Methodology input set is composed of:
Application(s)
Thread 1 Thread 2 Thread 3 Middleware
(Hardware Abstraction Layer) Hardware
driver (P1)
Hardware driver (P2)
Hardware driver (P3) General Purpose Processor
Coprocessor Unit (P1)
Coprocessor Unit (P2)
Coprocessor Unit (P3)
HardwareSoftware
Fig. 6. Software and hardware layers involved in the proposed system
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
Décomposi9on du problème d’analyse et d’extrac9on de l’informa9on en ≠ sous taches.
Application binary
Network application specification handwriting
Parser specifications Application
logic
Code compilation
Processor core
Zebra Dedicated
software
Hardware synthesis
Dedicated hardware
System on Chip for ASIC/FPGA
Parsing units (c) Methodology based on dedicated
hardware parser generation
Solu9on basée sur la généra9on et assemblage de par9es logicielles et matérielles.
Système ciblé dans le travaux:
+> un processeur;
+> des accélérateurs matériels.
Co-design based architecture for control intensive applica9ons, a
« blank » domain.
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Hardware accelerators for « parsing-based » applications (1/3)
๏ There exist (a few) related works on hardware
accelerators for text parsers.
๏ Two main formats were evaluated:
➡ XML stream parsers;
‣ XML is not a general use case;
➡ PERL regular expression parsers;
‣ regular expression parser is different from protocol parsers (automaton).
๏ No general solution…
➡ Only hardware coprocessor only was considered (no software interaction).
30
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Hardware accelerators for « parsing-based » applications (2/3)
๏ Stream-based architectures for deep-packet inspection,
‣ Very active domain;
‣ Very high-throughput.
๏ Deep-packet inspection
➡ Detect specific patterns;
‣ Generate « boolean » results;
➡ Check a set of detection rules.
๏ Do not extract information fields from messages;
➡ Useless for current problem.
31
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Hardware accelerators for « parsing-based » applications (3/3)
๏ Automated design flows for hardware accelerator
generation,
๏ Generates RTL architectures from C-like descriptions with High-level synthesis tools:
- Catapult-C, Vivado HLS, LegUp, C2RTL, GAUT, etc.
๏ Mainly designed to support data flow applications.
- Message based-parsers are control dominated applications…
32
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Proposed co-design based architecture for message-parsing acceleration
33
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
De l’application à l’architecture du système
๏ Co-design based architecture
➡ General Purpose Processor;
‣ Flexibility of the software;
‣ I/O peripheral management.
➡ Hardware coprocessors
‣ Processing performance.
34
La problématique consiste à
identifier les traitements à confier aux accélérateurs matériels.
Processeur généraliste
Accélérateurs matériels Controleur
ethernet Gestionnaire
UART
Controleur mémoire (DDRAM)
controleur VGA
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Message parser profiling to identify performance bottlenecks
๏ Les parsers sont constitués de 2 parties principales,
- L’automate qui implante l’analyse;
- Les fonctions de call-back qui réalisent les « actions ».
๏ Profiling de plusieurs parsers logiciels à l’aide de données réelles,
- 90% du temps d’execution est passé dans l’automate;
- 10% du temps d’execution est passé dans les fonctions de traitement.
๏ Résultats dépendants des données & des protocoles.
35
Hardware accelerator
"GET HTTP/1.1 …"
<action=31, pos=0>
<action=26, pos=2>
<action=??, pos=?>
Processor core
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Minimizing the amount of data transfers between elements
36
Hardware accelerator
"GET HTTP/1.1 …"
<action=31, pos=0>
<action=26, pos=2>
<action=??, pos=?>
Processor
core
GET the_video FORMAT mp4, avi, mpg
ACTION: GET POSITION: 2 PATTERN: NAME_START POSITION: 4 PATTERN: NAME_STOP POSITION: 13 ... ... ... ... ... ... ... ... ... ... ... ... ... ...
... ... ... ... ... ... ... ... ... ... ... ... ... ...
Paquet réseau 1 Paquet réseau 2
Afin de minimiser la
communication entre les 2 éléments, seuls les couples
(action, position) sont renvoyés
Accelerator
processing
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Les différentes couches logicielles développées
37
Application(s)
Thread 1 Thread 2 Thread 3 Middleware
(Hardware Abstraction Layer)
Hardware driver (P1)
Hardware driver (P2)
Hardware driver (P3)
General Purpose Processor
Coprocessor
unit (P1) Coprocessor
unit (P2) Coprocessor unit (P3)
Hardware Software
Codes sources indépendants de l’implantation logicielle ou matérielle
des parseurs
Couche logicielle fournissant les fonctions de bas niveau: transfert de
données, lecture de l’état courant...
Couche logicielle en charge de la fourniture de l’HAL. Identification, réservation et accès aux parseurs
matériels + gestion multi-threads
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Liens entre les différentes couches (diagramme de séquence)
38
socket Parsing layer driver coproc
App
get results wait finished
get results save state reset coproc
send data
load context
read
read parser_msg
parser_msg
reset reset
send data send data
get results get results
save context
load context
send data send data
General purpose
processor dedicated
co-processor Accelerator drivers
Middleware Application
Séquence d’actions impliquées lors d’une
analyse d’un message textuel
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Architecture du SoC / SoPC développée
39
Processeur (Léon)
Parser HTTP matériel
ALU
Controleur ethernet Gestionnaire
UART
Mémoire RAM
๏ Le système est basé sur l’association:
➡ Coeur de processeur généraliste (Leon-3),
➡ Accélérateurs matériels,
‣ Application de type contrôle intensif (automates),
๏ Intégration des accélérateurs dans le chemin de données
➡ Efficacité des communications,
➡ Extension du jeu d’instruction du processeur,
๏ Le processeur Léon-3 + accélérateurs peuvent être intégrés dans un SoC (ASIC)
Xilinx ML507 board
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Interface (E/S) des accélérateurs matériels
๏ Signaux de contrôle
➡ Transfert de données (write)
➡ Transfert de données (read)
➡ Chargement du contexte (multi-threads)
➡ Remise à zero (hard/soft)
๏ Interface pour les données
➡ DataIn: 8 bits ou 32 bits (1 ou 4 carac / cycle)
➡ DataOut: 32 bits (16/16)
➡ Context: 32 bits (16/16)
๏ Statut de l’accélérateur
➡ Fifo d’entrée Full,
➡ Fifo de sortie Empty,
➡ Calcul en cours / calcul terminé.
40
Input data
Parser HTTP matériel write data
Context Load Cont.
Output data
Curr. context
isProcessing isIdle NbOutputData
softReset hardReset
In Fifo full Out Fifo Empty read data
L’interface E/S des accélérateurs est indépendante de la spécification du parser.
Facilite la génération / intégration automatique
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Architecture du SoC / SoPC
41
General Purpose Processor
empty (1)
odata (32)
odata (32)
owe (1)
context for loading (32)
enable context loading (1)
we (1)
odata
(32)
idata (8)
4x (1)
Serializer
we (1)
coprocessor current context (32)
coprocessor identifier (32)
next state computation
logic
Output generation
State register
Coutner
Context encoder Context decoder
idle status (1)
processing status (1)
Constant ID ivalid (1)
read_en (1)
read_en (1)
odata
(8)
Coprocessor
Moore-based implementation
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Instructions permettant de dialoguer avec l’accélérateur
42
๏ Instructions assembleur contrôlant l’accélérateur matériel,
➡ pSoftReset( ) : réinitialise le contexte courant,
➡ bool pEmpty( ) : résultats en sortie du coproc,
➡ bool pFull( ) : entrée (data) pleine.
➡ void pWrite( char ) : envoyer une donnée au co- processeur,
➡ int pRead( ) : lire un résultat du co-processeur,
➡ bool pIsIdle( ) : le co-processeur est inactif,
➡ bool isProcessing( ) : le co-processeur est actif.
➡ int getContext( ) : lit les registres internes du coproc,
➡ void setContext( int ) : force la valeur des registres
internes du coproc,
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Flot automatisé de conception de systèmes SoC / SoPC
43
Network application
source codeS
ZEBRA tool
Logical synthesis
GCC tool chain
System design for SoC
Binary executable Message
parser descriptions
Softcore processor
sources
Modified softcore processor
(ASIP)
RTL coprocessor
source codes
C drivers + customized middleware 1
2
Network application
source codeS
3
4
5
6
7
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Protocol specification and « Zebra language »
44
A flexible SoC and its methodology... 12:11
Request = Request_Line
(( general_header
| request_header
| entity_header ) CRLF)*
CRLF
message_body? {clen} ∏;
Request_Line = Method SP Request_URI ^uri ∑ SP HTTP_Version CRLF;
Request_URI = ’*’ | absoluteURI | abs_path | authority;
entity_header = Allow
| Content_Length
| ...
Content_Length = ’Content-Length: ’ digit+ ^clen as uint32 ∂;
Fig. 9 . Excerpt of Zebra specification for HTTP
A set of logical synthesis and software compilation scripts finish the integration pro- cess on the hardware device selected by the software developer (Fig. 8 ª , º ).
4.6. The Zebra language
Protocol specifications (Fig. 8 ∑ ) are provided in the Zebra language. It is based on the ABNF notation used in RFCs to specify the syntax of protocol messages to ease its adoption by network application developers. Once having created a basic Zebra specification, the developer can further annotate it according to application-specific re- quirements. Fig. 9 shows an excerpt of the Zebra specification for the HTTP protocol as defined in RFC 2616. Annotations define the message view available to the application, by indicating the message elements that this view should include. These annotations drive the generation of the data structure that contains the message elements. For ex- ample, three message elements are annotated in Fig. 9. To make an element available, the programmer only has to annotate it with the ˆ symbol and the name of a field in the generated data structure that should store the element’s value. For instance, in Fig. 9, the Zebra programmer indicates that the application requires the Uniform Re- source Identifier (URI) of the request line (
∑). Hence, the data structure representing the message will contain one string field: uri .
Besides tagging message elements that will be available to the application, anno- tations impose type constraints on these elements. This can be specified using the notation as followed by the name of the desired type. For example, in Figure 9, the Content-Length field value (
∂) is specified to represent an unsigned integer of 32 bits ( uint32 ). A type constraint enables representing an element as a type other than string. The use of both kinds of annotations allows the generated data structure to be tailored to the requirements of the application logic. This simplifies the application logic’s access to the message elements.
In our experience in exploring RFCs, the ABNF specification does not completely define the message structure. Indeed, further constraints are explained in the accom- panying text. For example, the RFC of HTTP indicates that the length of the body of a HTTP message depends on the Content-Length field value. To express this constraint, the developer only has to annotate the variable-length field message-body (
∏) with the name of the field, between curly brackets, that defines its size ( i.e. , clen). Note that such fields must have be typed as an integer.
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
It is based on the ABNF notation used in RFCs to specify the syntax of protocol messages to ease its adoption by network application developers.
An excerpt of the Zebra specification for the HTTP protocol as defined in RFC 2616.
The programmer only has to annotate it with the ˆ symbol and the name of a
field in the generated data structure
that should store the element’s value.
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Evaluation of system performances
45
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Evaluation of system performances - Experimental setup -
46
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Developed system for approach benchmarking
47
๏ Objective was to develop a working
demonstrator on FPGA (freq < 100MHz),
๏ 4 network protocol subsets were
considered for parsing performance evaluation,
➡ HTTP (web)
➡ SMTP (mail)
➡ SIP (voie sur IP)
➡ RTSP (streaming)
๏ Different development boards were used during the project,
➡ Virtex-5 (ML507), Spartan-6 (SP605), Virtex-6 (ML605).
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Processor core selected for experimentations
48
Processor selected is LEON-3 softcore, developed by Gaisler for ESA.
LEON-3 is compatible with the SPARK-v8 instruction set specification.
32-bit processor core, 32 registers, 7 pipeline stages. It is also configurable.
Successfully implemented on
many ASIC & FPGA technologies.
Architecture SoC/SoPC pour les applications…
Bertrand LE GAL 18 / 11 / 2015
Complexity of the parser automatons
49
A flexible SoC and its methodology... 12:13
5. PERFORMANCE EVALUATION 5.1. Introduction to experiments
In order to evaluate the performance improvement achieved by the presented system compared to fully software based ones, a set of commonly used network protocols has been selected. Indeed, Zebra specifications for four of the most ubiquitous protocols on the Internet (HTTP, SMTP, SIP and RTSP) were developed. For each of them, we have used the Zebra compiler framework to automatically generate the VHDL architecture of the coprocessors and the associated software layers.
To highlight the complexity of the automata required to implement the selected net- work protocols their characteristics are provided in Table II that provides:
— the number of unfactorized transitions - It is the number of atomic transitions be- tween states: there may exist more than one transition from state x to state y when the conditions t
(x,y)are different;
— the number of factorized transitions - It is the number of complex transitions be- tween states: there exists only one transition from state x to state y disregarding the condition complexity.
Note that specifications used in our experiments only extract the most commonly used subset of the protocol tokens as usually performed in network applications such as those developed for monitoring network traffic, computing statistics, billing or en- abling NIDS based filters, or network protocol gateways [Bromberg and Issarny 2005;
Bromberg et al. 2009; Burgy et al. 2011]. For instance, our HTTP-based application records 4 fields for each request and response (date, host, uri for requests, status code for responses, and body). Although our HTTP specification extracts only four fields, it still consists of 55 rules and 300 different tokens. The number of specification lines that were required to specify the message protocol in the BNF like format were 97, 87, 128 and 80 for respectively HTTP, RTSP, SIP and SMTP protocols.
5.2. Hardware demonstrator on FPGA target
A prototyping system was developed targeting a Xilinx ML605 development board. Se- lected softcore processor was the LEON-3 [Gaisler Research 2010]. Processor choice was realized at the beginning of the study because (a) its VHDL source codes were open-source enabling core modifications and (b) its peripherals were fully compatible with Xilinx ML605 board. However, it is important to notice that the proposed ap- proach is not processor core locked, other softcore processors may be used instead of LEON-3 one e.g. Plasma [Rhoads 2009], Amber [Amber Open Source Project 2013], or Nios II [Altera 2014].
The LEON-3 processor is an embedded softcore processor that has been developed by Jiri Gaisler for the European Space Agency (ESA). This processor core has been suc- cessfully implemented on different FPGA devices and ASIC technologies. LEON-3 is fully compliant with the SPARK v8 instruction-set specification [SPARC International Inc. 1999]. Its internal architecture uses 7 pipeline stages and implements branch pre- diction techniques.
Table II. Complexity of the message parsing automata
Specification #states Unfactorized transitions Factorized transitions
#trans Avg
(trans/state)
Max
(trans/state)
#trans Avg
(trans/state)
Max
(trans/state)
HTTP parser 66 3922 59.4 98 209 3.2 7
RTSP parser 56 2722 48.6 84 150 2.7 5
SIP parser 284 17451 61.4 119 1790 6.3 19
SMTP parser 333 6974 20.9 86 1083 3.3 7
ACM Transactions on Embedded Computing Systems, Vol. 0, No. 1, Article 12, Publication date: January 2014.
0
1 'E'
'A' 'C' 'D'
0
( 'A' | 'C' <=> ''E' ) 1
