Methodology of Communication

Protocols Development: from

Requirements to Implementation
Irina Lavrovskaya, Valentin Olenev
{irina.lavrovskaya, valentin.olenev}@guap.ru

© Accellera Systems Initiative 1

COMMUNICATION PROTOCOLS
DEVELOPMENT

© Accellera Systems Initiative 2

 Communication Protocols Development
• Communication protocol is a set of rules
for the order in which messages of
particular types are exchanged
• Nowadays communication protocols are
widely used in different areas. Particularly,
in the following areas:
– Space and aircraft industry;
– Vehicle systems;
– Mobile industry (USB, UniPro, etc.);
– Computing (TCP/IP, etc.);
– Etc.
• The developed protocol should be
precisely investigated before being
implemented
© Accellera Systems Initiative 3
 Protocol Design Difficulties
increasing
complexity of
projects

demand to The modern

speed-up the
approach to the
project design
phase system design
implies the
increasing parallel execution
requirements
of some design
to products
reliability tasks

power
consumption

© Accellera Systems Initiative 4 4

 System General Design Flow:
Conceptual system design Collecting requirements for
the target system, evaluation
of the main system
Task-level design and System-level design and Elaboration of time,
choose of the optimal choose of the optimal energy and board area
Getting the final decisions decisions constraints description, analysis of the
version of the system mechanisms and
system development of the first
Specification
specification and specification draft
the system Spec. development

model in a high-
level language Functional spec. and research
(usually in
С/С++, SDL) Spec. improvement Logical deisgn Translation of the executable
Choose of technology
project specification to the
and library register level (in
Verification
Verilog/VHDL) and further at
Behavioral level modelling
the gate level

Testing Logical
Verification of synthesis
the design
decisions on This stage begins from the
conformity to selection of technological
Physical and library basis and it is
the specification
and other verifcation completed when everything
requirements
Physical design is ready for the final product
production

© Accellera Systems Initiative 5 5

 What do we Cover by our Methodology?
Generalised design flow Our approach
Requirements collection,
specification draft
Conceptual system design
Formal
Description
Technique

Development of Formal Errors, Specification

Specification inconsistencies Update
Specification

Formal spec Functional

requirements

Modeling and Verification Errors

Logical deisgn SUCCESS Non-functional

requirements

Verification Performance Analysis Errors

SUCCESS

Physical design

FAIL Implementation

© Accellera Systems Initiative 6

Collecting Requirements

© Accellera Systems Initiative 7

 Main Problems to Resolve
Requirements
collection,
Communication with • Different terminology;
the customer
specification draft
• Unclear requirements;
• Customer who:
 does not know what they
Development of Errors, Specification
Formal inconsistencies
Update
Specification
want;
 wants more than they need;
Formal spec

Modeling and Errors

 wants to get smth
Verification
absolutely new and keep all
SUCCESS
adjacent soft/hardware
unchanged;
Performance
• Some parameters and
Errors

Analysis

FAIL
requirements should be
held in confidence, e.g. in
SUCCESS

Implementation space industry

companies.
© Accellera Systems Initiative 8
 Main Principles of Collecting Requirements
Analyse the technical assignment, find “blank spaces”

Create a common vocabulary for both developer and customer

Create a draft questionnaire for the customer in accordance with possible functionality for the
developed protocol

Interact with the customer, discuss every little question

Do not ask the questions on which the customer cannot know the answer

Do not ask “how” or “what do you need”, but “do you need THIS or THAT”

Analyse the answers, are there any inconsistencies or ambiguities?

Ask more questions to be sure that the customer understands your questions and his answers.

© Accellera Systems Initiative 9

Specification and Description
Language Formal Spec

© Accellera Systems Initiative 10

 Formal Protocol Specification
Formal
• The objective of Requirements
Description
development: the target model
collection,
specification draft Technique
describes all mechanisms,
interactions and functionality
which are stated in the
Formal Development of Errors, Specification
specification. Specification
Formal
Specification
inconsistencies
Update

• There is a set of FDT: Spin, Formal spec

Estelle, LOTOS, Petri Nets, SDL,
etc. Modeling and Errors

• In our methodology we widely Verification

use Specification and SUCCESS

Description Language (SDL)
for protocol specification Performance Errors

• Results of this stage: Analysis

– consistent readable textual FAIL SUCCESS

specification
– formalised graphical specification
in SDL is produced which can be Implementation
used as a reference for the textual
spec
© Accellera Systems Initiative 11
 Specification and Description Language (SDL)
channel_1

• Standardized between 1976 and system Example signal_2

block Block1 signal_2

1992 by ITU-T
channel_1 r1

signal_1 signal_1

• High-level general-purpose Block1 Process1

graphical description language for channel_2 r2

event-driven, real-time and signal_3 signal_1

channel_3

communicating systems
Block2
signal_4 Process2

• SDL provides two representations:

r3
signal_3

– Graphical (SDL-GR)
channel_2

procedure Pr1 process Process2

– Textual (SDL-PR)
• Application fields: Pr1 Pr1

– telecommunication systems idle

– protocols signal_1

• Provides strong structuring signal_1

via r2

facilities which give an ability to idle

describe systems of all kinds of

difficulties
© Accellera Systems Initiative 12
 Formal Semantics: ECFSM State

• The system described by an SDL start

specification represents the Input
Extending Communicating Finite stimuli
State Machine (ECFSM) red

– It consists of a set of concurrent

processes, extended with variables r_off / y_g_off /
and data space. y_on r_on
– Communication is performed by
exchanging control signals on Output
finite-length asynchronous stimuli
yellow
channels. Output signals of one
process can be an input signal for
the another process.
– Each process consists of a set of y_r_off / g_off /
states. Transitions from one state to g_on y_on
another are performed in
accordance with the received
green Transition
signals.

© Accellera Systems Initiative 13

 Example of Protocol Stack SDL Specification
(N_CCind),

Upper Service N_CC_SAP

(N_CCcnf)

(N_CCreq), N_CFG_SAP
(N_CFGind)
N_DATA_SAP
(N_DATAind)
SDL
(N_CCrsp)
Access Point block type (N_CCcnf) (N_CCind) (N_CFGind)
(N_CFGreq)

N_WriteN_Char.cnf
(N_DATAreq)

N_ReadN_Char.ind
specification of
SpW_Node
the SpaceWire
N_CC_SAP_tx N_CC_SAP_rx N_CFG_SAP N_DATA_SAP_tx N_DATA_SAP_rx protocol stack
(N_CCreq) (N_CCrsp) (N_CFGreq) N_WriteN_Char.req N_ReadN_Char.rsp

N_CC_SAP_tx N_CC_SAP_rx N_CFG_SAP N_DATA_SAP_tx N_DATA_SAP_rx

NL: Network_Layer_Node

E_CC_SAP_tx E_CC_SAP_rx E_CFG_SAP E_DATA_SAP_tx E_DATA_SAP_rx

(E_CCcnf) (E_CCind) (E_CFGind) (E_DATAcnf) (E_DATAind)

E_CC_SAP_tx E_CC_SAP_rx E_CFG_SAP E_DATA_SAP_tx E_DATA_SAP_rx

(E_CCreq) (E_CFGreq) (E_DATAreq)

SpaceWire E_CC_SAP_TX E_CC_SAP_RX E_CFG_SAP E_DATA_SAP_TX E_DATA_SAP_RX Internal

protocol layer EL: Exchange_Layer interactions
blocks C_DATA_SAP_TX C_CFG_SAP C_DATA_SAP_RX via channels
C_SendChar.cnf C_LinkError.ind C_RcvChar.ind

C_DATA_SAP_tx C_CFG_SAP C_DATA_SAP_rx

(C_CFG_TX ),
C_SendChar.req (C_CFG_RX) C_RcvChar.rsp

C_DATA_SAP_TX C_CFG_SAP C_DATA_SAP_RX

CL : Character_Layer

S_DATA_SAP S_CFG_SAP

(S_DATAind) S_LinkError.ind

S_DATA_SAP S_CFG_SAP

Bottom Service (S_DATAreq)

Access Point
(S_DATAind) S_LinkError.ind
S_DATA_SAP
© Accellera Systems Initiative (S_DATAreq)
14 S_CFG_SAP
Modeling, Verification,
Performance Analysis

© Accellera Systems Initiative 15

 Protocol Modeling
Main goals of modeling
• Verification of the protocol functional properties;
• Investigation of compatibility and correctness of algorithms and methods
deployed in the specification;
• Investigation of protocol operation in case of error occurrence while data
transmission.

Modeling and investigation directions

• Specification and Description Language;
• SystemC modeling;
• C++ reference code;
• SDL/SystemC joint model.

Basic approaches
• Protocol stack modeling;
• Network modeling.

© Accellera Systems Initiative 16

 Approaches for Protocol Modeling (1/2)
Network modeling Protocol stack modeling
DEVICE 1 DEVICE 1

Device 2 Layer 4 Layer 4

Interface Interface

Layer 3 Layer 3

Interface Interface

Layer 2 Layer 2
Device 1 Router Device 3 Interface Interface

Layer 1 Layer 1

Goals:
• check the data transmission
• check the routing correctness
Benefits:
• The real interest represents here the
mechanisms of devices communications in
the network which is the key issue for the
performance analysis
We cannot consider:
• the protocol layers
• the interaction between protocol layers
• the forming of packets
• device’s operation with applications
Goals:
• check the presence of errors in specification
• check the packets generation
• check all internal mechanisms
Benefits:
• The set of modules breaks into the layers
forming hierarchy;
• Every layer communicates only with directly
adjoining layers.
We cannot consider:
• Interaction of devices in a network

© Accellera Systems Initiative 17

 Approaches for Protocol Modeling (2/2)
Requirements
collection,
specification draft

Protocol stack
modeling:
Development of
Errors,
Specification SDL, SystemC, C++
Formal
inconsistencies Update
Specification

Formal spec

Modeling and
Verification Errors Two approaches

SUCCESS

Performance Errors
Analysis
Network modeling:
FAIL SUCCESS
SystemC

Implementation

© Accellera Systems Initiative 18

Mapping of Modeling Directions to Design Flow Stages
Requirements collection,
specification draft
Formal
Description
Technique

SDL Development of Formal Errors, Specification

Specification inconsistencies Update

Formal spec Functional

SDL,
requirements

SystemC, Modeling and Verification

SDL/SystemC,
Errors

C++ reference SUCCESS Non-functional

requirements

SystemC Performance Analysis Errors

network model
SUCCESS

FAIL Implementation

© Accellera Systems Initiative 19

SDL Protocol Stack Modeling

© Accellera Systems Initiative 20

 SDL Protocol Stack Modeling SpaceWire-RT Node

Test Engine

• SDL is the most reasonable solution for ML

SAP
VCL_SAP

Virtual Channel
BL_SAP

Broadcast
modeling and validation on per layer basis.
ML
SAP Layer Layer
FL_SAP FL_SAP

• SDL model formally describes all mechanisms,

ML
SAP Framing Layer

Management Layer
RL_SAP

interactions and functionality stated in the ML

SAP Retry Layer

specification.
LCL_SAP

ML
SAP Lane Control Layer

• Generally, the simulated system consists of two

LL_SAP

ML
SAP Lane Layer

nodes which communicate via a model of a link.

EL_SAP

ML
SAP Encoding Layer
SERDES
SAP

Serialisation Layer channel

• Such kind of modeling gives an ability to:

– check and verify all internal mechanisms,
– validate the consistency of the specification and
– check functional requirements that were
defined for the protocol.
• Furthermore, such SDL models can be used as
a part of a tester.
21 © Accellera Systems Initiative
SystemC Network Modeling

© Accellera Systems Initiative 22

 SystemC
• SystemC is a C++ library for Functional
Requirements
modeling of embedded systems collection, requirements
and communication protocols specification draft

• The objective of development:

• check the communication Development of
Specification
protocol operation over the Formal
Specification
Update
network,
Formal spec
• test the network configuration,
• networking features and Modeling and
conduct the performance Verification

analysis Simulation SUCCESS

• In our methodology we widely use model

SystemC for network modeling Performance
and performance analysis Analysis

• Results of this stage: FAIL SUCCESS

Non-
• the final version of the system functional
specification Implementation
requirements
• the system model in a high-
level language
© Accellera Systems Initiative 23
 SystemC Advantages
• SystemC uses
– such primitives as channels, interfaces and methods,
– it gives high flexibility in modeling that could be based on various computation
models,
– provides possibility to integrate and use these models in parallel.
• SystemC is C++ based and this point makes cooperation in HW/SW design
easier.
• SystemC supports hardware modeling and detailing of a project to the RTL
level. Requirements Matlab

Architecture

Hardware/Software

Behavior
Application
SystemC
of modeling Functional Vera
in protocol Verification
e
design flow Testbench System PSL
Verilog
RTL Verilog VHDL

Gates

Transistors

24
 Modeling of Networks N0

link

• Generally, the network model consists of the Sw 0 N1

following SystemC modules: link link

– Nodes implementing the communication N7 link Sw 1 link Sw 2 link N2

protocol, link link

– Switches or routers, N6 link Sw 3 link Sw 4 link N3

– Traffic Generators, which operate over the link link

nodes and give ability to launch different tests N5 Sw 5

and generate test sequences. link

• Configuration parameters:
N5 N6 N7 N8 N9 N10 N4

N4 N11

– data transmission speed,

Switch Switch
N3 N12

N2

N1
N13

N14
– number of nodes and switches,
N0 N0

– time delay and routing table for the

N1 N1
N0
Switch N15

switch,
N2 N2
Switch
Switch

N3 N3

N4 N4
– number of ports in the switch, etc.
N0 Switch N7

• Ability to simulate operation of:

N5 N6 N6 N5
N1 N6

– the various numbers of devices

N2 N3 N4 N5

– networks with different topologies.

© Accellera Systems Initiative 25
© Accellera Systems Initiative
SDL/SystemC Co-Modeling.
Tester

© Accellera Systems Initiative 26

 Protocol Model Tester
• The objective of development: verification of Test sequences

the protocol specification, algorithms testing on

Tests API

Test Engine

the basis of the developed protocol model. Config

API
Socket API

SAP

• Such a Tester is able to: Tester

SAP
Layer 4

– validate the standard Direct D, S forcing

Physical Level

specification itself;
SAP SAP

SAP
Signal Level L3_L4 Interlayer

– validate the model for Bit flow SAP

Management Layer
SAP
Bit Error Layer 3
Character Level

correspondence to the Character

Character
type
Character
SAP SAP

specification;

SAP
Additional Nchar L2_L3 Interlayer
Exchange Level
Nchar, Connecti SAP
Mng
Nchar, ccode EOP ccode on state

– test prototypes or boards

_connection

SAP
EOP Layer 2
Packet Level
SAP SAP

in production;
Packet

SAP
(header + data) L1_L2 Interlayer

Errors Network Level

– certify products, verify

SAP

SAP
Packet
Layer 1
Packet

products for
(data+
(data)
Dest.ID) Tester

conformance with the

Common Transport

standard. RMAP STP Other transport protocols

© Accellera Systems Initiative 27

 SDL/SystemC Tester
SDL/SystemC tester is a flexible
SDL tool for:
Model • setting different
SDL / configurations;
• generating various test
SystemC sequences;
Tester • gathering statistics.
SystemC Test
Environment

SystemC SDL/SystemC up wrapper

The Tester gives the following abilities: UP SAPs UP SAPs

• representation of tested layers by Application Application

means of finite state machine Node #0

Node #1
Transport Transport
• access not to the whole SDL model only
but also to certain layers of stack Network Network
through appropriate Intermediate
SDL

SDL
Blocks Data Link Data Link
• getting all necessary test results by LOW SAPs LOW SAPs

SystemC implementation of the test SystemC SDL/SystemC low wrapper

environment
© Accellera Systems Initiative 28
 Organization of SDL and SystemC Co-Modeling
• SDL and SystemC can be combined in one
model so as to: Protocol SDL Model
– use SDL as a basic FDT for specification, verification
and performance analysis “make” (compilation)

– use SystemC for creation of complex test sequences SDL part of Tester

and to provide wide facilities to work with time generated ctrl

– perform all investigations on the basis of one model code
SDL core
of the protocol. data

• Basic structure of SDL/SystemC co-model:

– SystemC provides simulation core and test
environment
– SDL provides formal protocol implementation
• General principles:
– SDL model is compiled into C-code, equivalent to the original model
– Generated C-code together with the SDL core is integrated into the
SystemC project

© Accellera Systems Initiative 29

 Protocol SDL Models Tester
SDL protocol models Tester

SystemC
Test Engine
Node0 Node1

SDL/SystemC

Node0

Node1
Modeling Core

Node0 Node1

Medium
SystemC

The Tester contains three parts:

• Test Engine – contains conformance tests and Tester control features
• Modeling Core – model of the tested protocols or protocol stack which are
implemented according to the protocol specification in SDL
• Medium – ensures interconnection between tested nodes inside the Modeling
Core

© Accellera Systems Initiative 30

 Modeling Core
Communication T T SystemC
Wrapper IB_T IB_T Intermediate blocks of Communication Wrapper
T T
SDL/SystemC Wrapper SystemC Test Engine
Node0

Tp Tp IB_N
Transport Layer (L4) Transport Layer (L4)
Np Np
Nu Nu
Nu Nu
IB_N

N
IB_N
N

Np

SDL/SystemC Wrapper
Np Np Network Layer (L3)
Network Layer (L3) Network Layer (L3) Du
Du Du IB_D
Dp Dp
SDL model IB_D D

D
IB_D
D

Dp Dp Du Du
Data Link Layer (L2) Data Link Layer (L2) Dp
Pu Pu Data Link Layer (L2)

IB_P Pu
P

IB_P

P
IB_P
Pp Pp
Pp Pp
Physical Layer (L1) Physical Layer (L1)

Mu Mu Pu Pu
SDL
Node0

Medium
M M
IB_M IB_M
M M - module implemented in SystemC

The Modeling Core consists of:

- module implemented in SDL

• Tested SDL model

• SDL/SystemC Wrapper
• Communication Wrapper
31
 Modeling Core
• Each Intermediate Block can provide the following features:
– managing data flows transmitted through the Communication
Wrapper
– parsing transmitted data – introduced for getting information
about data exchange between two adjacent layers
– making logs – used for monitoring of results
– error injection – introduced for testing of error detection
and/or error correction possibilities of a tested protocol
• Key issues for SDL model implementation:
– each layer shall be represented by one SDL block
– all required layers should be joined to one SDL system
– each two adjacent layers of one node can be connected in two
ways:
• through an SDL channel only
• through an appropriate Intermediate Block
© Accellera Systems Initiative 32
 Test Engine

• The Test Engine module is responsible for control

of the SDL model simulation
• The Test Engine tasks:
– Configuration of the SDL model Communication
Wrapper before the start of test sequence
– Configuration of the Medium. During this phase
channel parameters such as the channel delay and the
error injection are defined
– Data exchange with the tested SDL model. The Test
Engine operates in accordance with a protocol of the
chosen layer and uses services of the layer below

© Accellera Systems Initiative 33

 The Medium
Node0 Node1
Medium

L1 Channel

Mp

Mp
set of
Pp L2 Channel channels

Pp
Control implementing
L3 Channel block a particular
Dp

Dp
data transfer
protocol
L4 Channel
Np

Np
introduction of
logs
delay

error injection

© Accellera Systems Initiative 34

C++ Reference Model

© Accellera Systems Initiative 35

 Reference Code
• The reference code is a software implementation of a protocol in
C++ language;
• The objective of development: create a reference for the
programmers, who will implement the protocol in the software as
well as use it as a part of a joint hardware/software tester;
• The C++ reference code describes:
– the logical structure of the protocol,
– its interfaces,
– all internal mechanisms.
• This reference code can be used for:
– studying of the protocol functionality;
– translation into the other programming language;
– implementation of a protocol in the software;
– hardware/software testing.
© Accellera Systems Initiative 36
Hardware/Software Testing
DUT is a device which shall be checked
set of test cases on conformance to the protocol
for checking specification.
DUT operation DUT can be represented by either:
• Hardware
• Software

HW/SW Tester
User
Interface
reference
Test cases
implementation
of the tested
protocol C++ reference
Device Under Test

Error Generator

HW Driver
module for testing
non-nominal cases
Hardware

© Accellera Systems Initiative 37

IP-Core Development
© Accellera Systems Initiative 38
 IP-core Development
• IP-core (or IP-block) is a reusable
Requirements
unit of logic, cell, or chip layout collection,
design specification draft

• The objective of development:

– check the hardware Development of
Specification
implementation of the protocol, Formal
Update
Specification
– check the operability of the
protocol’s mechanisms,
Formal spec

– evaluate hardware costs. Modeling and

• In our methodology we use VHDL Verification

for implementation of IP-blocks SUCCESS

• Results of this stage:

– IP-block area estimation; Performance
Analysis
– Clock frequency estimation;
– Power consumption characteristics;
FAIL SUCCESS

– Protocol ready or not for the

hardware implementation. IP-core Implementation

© Accellera Systems Initiative 39

 The protocol controller implementation:
Typical structure of IP-block
determined by
a standard Controller (IP-block)
Main concerns on reusability
Functional part
in different network-on-chip
(NoC) projects:
Block1 Block2 Block3
System
interface • Varied technologies (FPGA,
Block7
controller
ASIC), different technology
Block4 Block5 Block6
process (libraries);
• Different standards of NoC
RTL model, written in HDL (VHDL, Verilog) – independent system interface (e.g. AXI,
from technology library
OCP).
Component from technology library (e.g. – memory block
for FIFO implementation)

• depends on SoC (NoC)

interface
• common problem: different
standards

© Accellera Systems Initiative 40

 Issue of Varied Technologies
1
• Separation of technology dependent sub Controller (IP-block)

blocks to a particular “tech” block, Functional part (main)

• Development the special “tech” block for Block1 Block3 System

interface
used technologies controller
Block4 Block6

2
using “if… generate” Block7 Block2 Block5

for every technology Functional part

(technology dependent)
dependent sub block
Controller (IP-block)
A_mem: for I in 1 to 1 generate
A_FPGA_Virtex_5: if tech_parameter = fpga_virtex_5 generate Functional part
A_buf: xRAMB16_S36_S36
port map(DOB=>QB_copy(31 downto 0),
DOPB=>QB_copy(35 downto 32), Block1 Block2 Block3
… System
end generate interface
Block7
controller
A_ASIC_1_90: if tech_parameter = ASIC_1_90 generate
A_buf: SRAM16x36 Block4 Block5 Block6
Port map(DB =>QB_copy,
…
end generate;
end generate;

© Accellera Systems Initiative 41

Issue of Different NoC System Interface Standards
1 Development of the special 2 Utilize a Bridge between the IP-
block of a system interface block and communication system
controller for every communication
standard IP-block
IP-block
System
Functional
interface bridge
System part
Functional controller
interface
part
controller

AXI bridge

Possible to AHB bridge

Possible to use AXI

implement this
OCP bridge
WISHBONE
an approach AHB
bridge either use
bridge
OCP
similar to the WISHBONE
the ready decision
previous issue from Design&Reuse

© Accellera Systems Initiative 42

OUR EXPERIENCE

© Accellera Systems Initiative 43

 Modeling Directions in Projects
SDL
• UniPro (MIPI Alliance)
• SpaceWire (University of Dundee,
ESA)
• SpaceWire-RT (FP7 project)
• STP-ISS protocol (JSC Information
Satellite Systems)
SystemC
• UniPro, PIE (MIPI Alliance)
• SpaceWire, RMAP, STP (University of
Dundee, ESA)
• SpaceWire-RT
• STP-ISS protocol, Plug-n-Play (JSC
Information Satellite Systems)

SDL/SystemC C++ reference

• UniPro • STP-ISS protocol
• SpaceWire-RT
• SpaceWire

© Accellera Systems Initiative 44

 Thank you!
Questions?

© Accellera Systems Initiative 45