Bar Ilan University

School of Engineering
VLSI Lab

OTN Framer

Netanel Gonen
Maayan Morali

Academic Advisor: Prof. Shmuel Wimer

Instructor: Mr. Moshe Doron
 Final Fourth Year Project
Computer Engineering

Table of Content

Introduction..........4
Theoretical Background.......5
Goals.......11
General Structure...12
TOP module13

The Transmitter ........16

Transmitter modules

TopTx.......17

DataPreparation........20

Tx_Mux.......22

FrameCreating.......24

OutMux.......26

Scrambler......27

The Receiver..........29

Receiver modules

Rx_top.....32

OTN Framer Page 2

 Data_reception.....34

Aligner.....36

De-scrambler.......39

Data_arrange.......40

Demux.......43

Hardware environment..45

Software environment.46

Implementation Stages.48

Challenges and Solutions....49

Future Ideas....51
Summary......52
Bibliography.......53

OTN Framer Page 3

Introduction
Due to the large scale globalization process active nowadays, information exchange
has become a critical issue, requiring the elaboration of faster, flexible and reliable
computer networks. The migration of network technologies to faster protocols
(Gigabit / 10 Gb Ethernet) forces the utilization of optical fiber links in both local
(LAN) and metropolitan (MAN) network backbones.
OTN (Optical Transform Network) is the only standard capable of transporting
10Gb entirely (and this is the reason we use it).

In this project we implement the OTN Framer, when our main goal is data
transporting at the rate of 10Gbps. In our implementation there are four data
sources and four data destinations. The Framer acts also as a Data Router, operating
under Network Management supervision. Each source can be routed to any
destination.

The implementation is based on the structure of the data units Multiframes.

Each Multiframe contains up to 256 frames. The frame has 4 rows of 4080B each,
and contains 3 main parts:

Headers first 16B of the row, contain data of routing, monitoring and
structure.
Data data from the sources.
FEC Forward Error Correction.

The OTN Framer Consists of:

Aligner Each frame has a sequence in its first 6B (FAS = Frame Aligner
Sequence) which indicates a beginning of a new frame. The Aligner
recognizes that sequence.
Data multiplexing the data coming from the 4 sources is multiplexed
before transmission
Scrambler the frames data (all except the FAS) is scrambled and
transmitted. The receiver also has a scrambler in order to Descramble the
data it receives.
Frames building the frames are built and consist mainly of the sources
data, but the framer must add the Headers and FEC in order to conform to the
ITU-T G.709 standard. The receiver should use the headers and FEC and move
the correct data to the appropriate destinations.

OTN Framer Page 4

Theoretical Background
The need for faster and improved data transmission led to utilization of optical
fiber links. As optical component technology has improved, it has become possible
to increase the traffic sent over a fiber by sending multiple signals, each on its own
wavelength, rather than increasing the rate of a single signal Such multiplexing is
referred to as wavelength-division multiplexing (WDM).
The Optical Transport Network (OTN) is a network using the ITU-T Rec. G.709
standard for Wavelength Division Multiplexed (WDM) signals, which is lowering the
cost of the network. However, the main characteristic of the OTN standard is the
presence of an error correction structure, based on the Reed-Solomon(255, 239)
algorithm. This structure may correct up to 128B in a burst for each frame, enabling
the use of longer optical links.

The OTN Protocol

The ITU-T is a branch of the International Telecommunication Union (ITU)

responsible for analyzing and organizing groups to study and create
recommendations for the telecommunication field.

The Optical Transport Network (OTN) standard is described in the G.709 ITU-T
recommendation, which defines an OTN interface as a set of elements for optical
networks capable of providing transporting functionality, multiplexing, routing,
management and supervision of optical channels.

The OTN interface must have the ability to carry signals from different types of
clients, as shown in the Figure:

OTN Framer Page 5

The OTN frame is composed of 4 lines of 4080 bytes, and divided to three main
blocks:

Overhead (16 bytes), Payload (3808 bytes) and FEC (256 bytes).

The OTN transmission does not follow the logic structure of the frame. It is
transmitted column by column as depicted in the Figure:

The OTN standard uses clock regeneration hardware on its receivers, therefore, long
sequences of 0s or 1s can compromise the clock regeneration process and
should be avoided. To avoid those long sequences, OTN transmitters use a
scrambling process on the OTN frames before transmission.

OTN Framer Page 6

Scrambler

The scrambling process operates conceptually as a Linear Feedback Shift Register

(LFSR), using the generating polynomial .

The output of the scrambling process is added to each bit of the multiframe.

Scrambling is applied after the FEC calculation for all multiframe bytes with the
exception of the FAS (Frame Alignment Signal) bytes. This process is symmetric, i.e.,
the same process used for scrambling the transmission signal, is used during the
receiving process to obtain the original descrambled signal.

In the OTN Framer project the implementation of the scrambling is performed in

one clock cycle, by using 48 XOR gates, when the values were pre-calculated by
Matlab and saved in a file Scrambler_ROM.coe. The ROM includes this file, and the
scrambler uses one value each time and XORs it with the unscrambled data.

Recommendation G.709 defines the OTN multiframe which contains 4 frames (4080
bytes lines, totalizing 16320 bytes). The OTN multiframe is organized in lines, and is
composed by the overhead, payload and FEC for each line. The OTN multiframe is
transmitted line by line.

OTN Frame Structure

OTN Framer Page 7

The 3 main parts in the frame are:

Headers
Payload
FEC

Headers:

FAS:
The FAS includes the 6 first bytes of a multiframe. It consists of the sequence
F6F6F6282828. The receiver has a framer which contains 48 comparators
comparing the receiving data and this sequence, when equality means a
beginning of a new data stream.

MFAS (Multi-Frame Alignment signal):

The value of the MFAS byte is incremented each frame providing, thereby a
256 ( ) frames on each multi-frame.

OTU (Optical Channel Transport Unit):

The OTU overhead provides supervisory functions to the OTU terminal
points. It consists of: three bytes Section Monitoring (SM), a two-byte General
Communication Channel (GCC0), and two bytes reserved (RES) for future
use.

GCC0:

OTN Framer Page 8

 We used 5 bits (LSB) of these 2B for routing data. For 4 data sources and
destinations there are 24 optional combinations of source-destination.
Therefore, we need 5b for routing.

ODU overhead:
The ODU information structure provides tandem connection monitoring
(TCM), end-to-end path supervision, and client signal adaptation via the
optical channel payload unit (OPU).
The path monitoring (PM) field in the ODU has a similar structure and
function to the section monitor field in the OTU overhead.

The ODU also defines six fields for TCM. TCM enables a network operator to
monitor the error performance of a signal transiting from its own network
ingress and egress points.
The six TCM fields provide support for tandem connection monitoring in a
variety of network configurations, and can cope with nested, overlapping and
cascaded topologies, as shown in the figure:

Two two-byte general communications channel fields, GCC1 and GCC2, are
defined in row 4 columns 1 to 4. These bytes provide a clear channel
connection between ODU termination points. The format of the data carried

OTN Framer Page 9

 in this channel is not defined.
The main purpose of these bytes is to carry operator management data.
Two fields (RES) are reserved for future standardization and are located in
row 2 columns 1-3 and row 4 columns 9-14. These bytes are normally set to
all zeros. Finally, a two-byte experimental (EXP) field is defined for
experimental purposes. This field will not be subject to future
standardization.

Payload

OPU Payload:
The OPU overhead is added to the OPU payload and contains information to
support the adaptation of client signals. The justification control (JC) bytes
are used to control the negative justification opportunity (NJO) or positive
justification opportunity (PJO).

The mapping process generates the JC, NJO and PJO values respectively.
The payload structure identifier (PSI) field is defined to transport a 256-byte
message aligned with the OTU MFAS.

FEC

FEC ( Forward Error Correction):

The FEC scheme used in the ITU-T G.709 standard is a Reed-Solomon RS
(255,239) code. For every 239 bytes of data, 16 bytes (255-239=16) of data
are added for error detection and correction. Before FEC processing, each
OTU row is separated into 16 sub rows, in order to increase burst error
performance. Each FEC encoder/decoder processes one of these sub-rows.
The FEC data bytes are calculated over the 239 information bytes of each sub
row and transmitted in the last 16 bytes of the same sub-row. The RS
(255,239) code can correct up to 8 symbol errors in the code word when

OTN Framer Page 10

 used for error correction. It can also detect 16 symbol errors in the code
word when used for error detection only.
In this project, the FEC was not implemented due to lack of time and based
on the fact that in a 10Gb rate the FEC is not mandatory.

Goals
Optical Transport Network (OTN) protocol is a new network protocol employing the
edge of technology making data transfer faster and more reliable.
As such, it requires complex hardware and software implementation.
The main goal of our project: designing an Optical Transport Network (OTN) Framer
A network element responsible for analyzing and processing OTN frames at the
client side according to the ITU-T advance protocol G.709.

In thisproject we constructed the Verilog code of the protocol algorithm and used
this implementation on the Virtex 6 FPGA (by Xilinx). We tested and simulated the
code in order to get a correct implementation of both transmitter and receiver.

Our project consisted of the following stages:

1. Protocol Learning Reading and understanding the complex protocol of the

ITU-T G.709. The basis for the project was the fundamental understanding of
the Optical Transport Network protocol documentation. As a starting point
we began researching network concepts including preceding technologies,

OTN Framer Page 11

 the SONET/SDH optical protocol used worldwide.
We have come to learn that the two technologies are closely related and that
the OTN is an enhancement of the aforementioned SONET/SDH.
2. Studying the FPGA Development boards available and choosing the most
suitable one among them.
3. Verilog Learning Reading tutorials, writing and learning code examples.
4. Code Implementation Creation of the system consisting of Transmission and
reception, using the Optical Transport Network Protocol.
5. Simulating and checking the code in the tools: SimVision (Cadence), ISE (of
Xilinx).
6. FPGA burn - burning the Virtex 6 FPGA, located on the Xilinx ML-605 Board,
with the code, finish the projects presentation.

OTN Framer Page 12

General Structure

OTN Framer Page 13

TOP module

Inputs

Din1 (48bit) - System input from port1.

Din2 (48bit) - System input from port2.
Din3 (48bit) - System input from port3.
Din4 (48bit) - System input from port4.
Routing info - The routing input. Which input should go to which
output.
Clk - System clock
Clk_sampling - the sampling clock.
En - system enable.
Nrst_top - system active low reset.

Outputs

Dout1 (64bit) - data out to port1.

Dout2 (64bit) - data out to port2.
Dout3 (64bit) - data out to port3.
Dout4 (64bit) - data out to port4.
Valid_out - Flag indicating a new data is in the output.

OTN Framer Page 14

 Description:

The OTN Framer Top Module Gets data from 4 sources (ROMs) and outputs
the data to 4 destinations (RAMs). It contains 2 modules: TopTx and rx_top.
Each module represents a different part in the system the transmitter and
the receiver. The transmitter transmit the scrambled data and the receiver
receive the data, desrambles it and put it in RAMs.

The top module contains 2 modules:

1. TopTx
2. rx_top

OTN Framer Page 15

OTN Framer Page 16
The Transmitter
In the OTN Framer Project, the Transmitter is the start point for the data. Every 4
cycles the Transmitter samples 48bit x 4 of data from its inputs, and every cycle it
transmits 48bits to the Communication Line. It adds to each transmitted frame a
Start-of-Frame bits sequence, multiplex the data from the 4 data sources, adds
headers and FEC (Forward Error Correction, after calculation of the FEC), scrambles
the data, and transmits the data.

Basic assumptions

The FEC in our project will be set to its default value 0. According to the STD, only in
100Gbps rate, FEC usage is mandatory.

The data is transmitted in full frames (no partial frames in the system).

Data Flow

The data flow works as flowing:

1. Sample 48bits x 4 from the input data each 4 clk cycles.

2. Create frames:
- Add headers (16Bytes on each row in the frame).
- Multiplex data from 4 data sources (3808Byes on each row).
- Add FEC bytes (256Bytes on each row).
3. Scramble each 6Bytes of data
4. On each Start-of-Frame add the sequence F6F6F6282828.
5. Transmit the data (48Bytes on each cycle).

OTN Framer Page 17

Transmitter modules

Tx module is divided to several smaller modules. Each one of them has specific
function.

TopTx

Inputs:

Clk System clock.

clk_sampling - System sampling data clock.
nrst System active low reset.
en System enable
FECenable FEC enable
Routing (5 bits) Routing data (there are 4!=24 option of source-
destination combination)
data_in1 (48 bits)- Raw data from source 1
data_in2 ( 48 bits)- Raw data from source 2
data_in3 (48 bits)- Raw data from source 3
data_in4 (48 bits)- Raw data from source 4

Outputs:

data_out (48 bits)- Transmitted data

OTN Framer Page 18

Description:

TopTx module gets data from 4 sources and transmits the data to the
Communication Line.
The process contains adding headers, multiplexing , adding FAS (Frame
Alignment Sequence) and FEC (Forward Error Correction), scrambling the
data and transmission.

The TopTx contains 6 components:

din_FIFO_1
din_FIFO_2
din_FIFO_3
din_FIFO_4
DataPreparation
FrameCreating

TxTop contains 4 FIFOs in order to save the sampled data in the correct order. Each
FIFO gets data from another input (data_in1, data_in2, data_in3, data_in4) .The data
that outputs from the FIFOs is the input of the DataPreparation module.

TxTop directs UnscrambledData from the output of DataPreparation module to the

input of FrameCreating module. The UnscrambledData value is the unscrambled

OTN Framer Page 19

data the multiplexed data with the headers and FEC. The data should be scrambled
and then the FAS should be added on each Start-of-Frame.

OutMuxEn, StartOfData and EndOfFrame are also directed from the output of
DataPreparation module to the input of FrameCreating module. OutMuxEn
becomes 1 when the first headers are ready (the first cycle that prepares 6Bytes of
headers for the first frame). StartOfData becomes 1 when the first bytes of the first
frame are ready and EndOfFrame becomes 1 when a frame is finished.

In order to get 10Gbps rate, we need to sample the data in a 46.667MHz rate. The
transmission rate is 200MHz, so the ratio between the clk rates is ~4.285683. After
testing the system with these rates, we
decided to use 50MHz instead of 46.667MHz
in order to prevent underflow of the FIFOs
that contains the sampled data. (an
unexpected error). The clk rates are created
by a PLL (Phase-locked loop).

The PLL is created by the Xilinx ISE CoreGen

utility. It outputs 2 clks:

1. 200MHz System clock.

2. 50MHz sampling clock.

The PLL is included in the Presentation module which includes the TxTop and
top_rx and responsible for the presentation of the input and output images on the
screens.

Reading from the FIFOs is faster than the writing the clk rate is higher, but the
reading is disabled every last 256Bytes in a row- because a default (=0) FEC is
transmitted there. The rates handle 2 problems that might Damage the process:

1. FIFO overflow
2. Reading from an empty FIFO

OTN Framer Page 20

DataPreparation

Inputs:

Clk System clock.

nrst System active low reset.
en System enable
FEC_en FEC enable
Routing (5 bits) Routing data (there are 4!=24 option of source-
destination combination)
data_in1 (48 bits)- Raw data from source 1
data_in2 ( 48 bits)- Raw data from source 2
data_in3 (48 bits)- Raw data from source 3
data_in4 (48 bits)- Raw data from source 4

Outputs:

UnscrambledData (48 bits)- Transmitted data

FrameCreatingEn- Enable for the FrameCreating module
EndOfFrame- Indicates an end of frame
ReadDataEnable- Enables reading from FIFOs (in TopTx)
StatOfData- Indicates the time of data preparation in the
frame
OutMuxEn- Enables OutMux module

OTN Framer Page 21

Description:

The DataPreparation contains 1 module:

1. Tx_Mux

DataPreparation prepares the data for the frame creation. The Headers are set in
this module routing bits and FEC_en come from its input. The data sources from its
input are wired to the Tx_Mux module.

OTN Framer Page 22

Tx_Mux

Inputs:

Clk System clock.

nrst System active low reset.
en System enable
din1 (48 bits)- Raw data from source 1
din2 ( 48 bits)- Raw data from source 2
din3 (48 bits)- Raw data from source 3
din4 (48 bits)- Raw data from source 4
headersData(464bits) Headers for one frame (4 rows)

Outputs:

dout (48 bits)- Data after multiplexing

endOfFrame - Indicates an end of frame
FrameCreatingEn- Enables FrameCreating module
OutMuxEn- Enables OutMux module
ReadDataEnable- Enables reading from FIFOs (in TopTx)
StatOfData- Indicates the time of data preparation in the
frame

OTN Framer Page 23

Description:

Tx_Mux is the module that multuplex the data from 4 data sources, and adds
headers and FEC to the frame. This module is also responsible for advancing the
MFAS (Multi-FAS) which contains 8bits counter of frames in the multiframe (0-
255).

This module includes a Finite State-Machine (FSM).

The states:

WaitForEnable : Waits for En

FAS: transmission of FAS
Headers : One or two cycle of headers (in the first row of a
frame, FAS already exists - one cycle of headers . others - two
cycles)
HeadersAndData: Four Bytes of headers (there are 16Bytes of
headers. 12Bytes are transmitted in 2 cycles of 6Bytes each.
The other 4Bytes are transmitted with 2Bytes of data)
DataCycle1: First cycle of data
DataCycle2: Second cycle of data
DataCycle3: Third cycle of data
DataCycle4: Fourth cycle of data
DataAndFEC: Four bytes of data and two bytes of FEC
FEC: transmission of FEC

OTN Framer Page 24

FrameCreating

Inputs:

Clk System clock.

nrst System active low reset.
en System enable
DataIsReady Equals 1 when the data is ready for scrambling
UnscrambledData (48 bits)- Data in
NewFrame- Equals 1 when its the beginning of a new
frame

Outputs:

data_out (48 bits)- Scrambled and multiplexed data

OutMuxEn- Enables OutMux module

Description:

The FrameCreating contains 2 modules:

1. OutMux
2. Scrambler

This module is responsible for the frame creation scrambling the multiplexed data
and adding the FAS in every start-of-frame.

OTN Framer Page 25

FrameCreating directs data_out from the output of scrambler module to the input
of OutMux module. This signal represents the scrambled data that should be
transmitted.

OTN Framer Page 26

OutMux

Inputs:

Clk System clock.

nrst System active low reset.
en System enable
ScrambledData (48 bits)- Data in
BeginNewFrame - Equals 1 when its the beginning of a new frame

Outputs:

dout (48 bits)- Scrambled and multiplexed data

Description:

OutMux module is a simple mux, the output depends on the state-

if its a new frame (BeginNewFrame = 1), transmit FAS
Otherwise transmit the scrambled data.

OTN Framer Page 27

Scrambler

Inputs:

Clk System clock.

nrst System active low reset.
Valid_in Indicatees whether the input data is valid or not
ROM_Addr(12bit)- Adress in ROM
data_in(48bits) - Data in

Outputs:

data_out (48 bits)- Scrambled and multiplexed data

valid_out- Indicates whether the scrambled data is valid

Description:

The implementation of the scrambler is performed in one clock cycle, by using 48

XOR gates, when the values were pre-calculated by Matlab and saved in a file
Scrambler_ROM.coe. The ROM includes this file, and the scrambler uses one value
each time and XORs it with the unscrambled data. The address of the ROM
memory the input wire ROM_Addr is advanced each clk cycle. The Descrambler is
the same component since XOR is an associative action. That means that:

OTN Framer Page 28

( ) ( ) And ( ) and ( ) . So performing the
scrambler XOR again returns the data to its original form.

The scrambler equation:

If the valid_out = 0 it means the data is not valid, and the output becomes 1.
If the Valid_in = 0, the output becomes 1 and valid_out becomes 0;

OTN Framer Page 29

The Receiver
In the OTN Framer Project, the Receiver is the end point for the data. Every cycle the
Receiver gets 48bit from the Communication Line. It detects the Start-of-Frame bits
sequence, unscrambles the data, reads the headers, and sends the reordered data to
its destination.
FEC (Forward Error Correction), is mandatory by the IEEE G.709 Standard, only at
100Gbps rate.
In the current Project, 10Gbps Channel (4 X 2.5Gbps ) has been implemented. FEC
infrastructure has been designed but FEC Generation and Decoding, was left for next
year Project implementation.

Basic assumptions
The OTN Receiver (or "Rx") gets an integer number of Frames. Every Frame will be
according to the IEEE G.709 OTN standard definitions. Every Frame is constructed
from 4 rows each containing 4080 Bytes divided as follows:

1. 16Bytes of headers
2. 3808Bytes of payload data
3. 256Bytes of FEC

In the OTN Framer there is no headers data except 3 items: the FAS (Frame
Alignment Signal), the MFAS (Multi FAS) and the routing information. The Rx will
use the FAS to indicate the start of a Frame and to align the data from the noise,
calculate data offset (in bits) within the received 48bits input samples and align data
accordingly. In addition, the Rx uses the routing information to send every received
Byte to its destination port.

The FEC in our project will be set to its default value 0.

Data Flow
See Fig 1.
The Receiver acts also as a Router and can handle routing ability to four outputs,
according to specific header information, included in received packets (4! = 24
possible options).

The data flow works as flowing:

1. Sample 48bits from the Optical Coupler.

2. Wait until Aligner module detects the FAS Sequence (F6F6F6282828)

OTN Framer Page 30

 1. If no FAS has been detected, return to stage 1.
3. FAS has been detected
4. Unscramble the data.
5. Arrange the data in 3 main register
i. Header register will hold the header data (16*4=64B).
ii. FEC register-will hold the FEC of 1 line (256B).
iii. Payload data register-will hold a data of 1 row (3808B).
6. After a full line was received need to compare FEC (not in our project).
7. Send each clock 128b of data to the demux.
8. Every 2 clocks (received 256b of data) de-encapsulate the data.
9. Send to de-encapsulate data to the outputs according to routing info in the
header.

OTN Framer Page 31

 Rx data flow

48bit from Tx

No
Aligner Fas received?

Yes

De-Scrambler

Fec register

Data arrangment

Headers
register

Temp data
register

output1 output2 output3 output4

OTN Framer Page 32

Receiver modules

Rx module is divided to several smaller modules. Each one of them has specific
function.

Rx_top

Inputs:

Din (48b) - System input. Contain noise until data starts from the
transmitter.
Clk System clock.
nrst_top - System active low reset.

Outputs:

Dout1 (64b) - output to port number 1.

Dout2 (64b) - output to port number 2.
Dout3 (64b) - output to port number 3.
Dout4 (64b) - output to port number 4.
Rx_valid_out - flag, indicating new valid output data.

OTN Framer Page 33

Description:

The rx_top modules receives 48bit input from the user, output 4*64 bit ports
and announce that a new data is ready.

The rx_top contains 2 modules:

1. Data reception.
2. Data arrange.

The rx_top module directs the output of the data reception module (reception_dout)
to the input of data arrange module (din_arrange) and the validation of the
reception_dout to the enable of the data arrange.

OTN Framer Page 34

Data_reception

Inputs:

din (48b) - The input from the rx_top module

containing the original input of the Rx.
Clk - System clock.
Nrst_top - System active low reset.

Outputs:

Reception_dout (48b) - valid, aligned and unscrambled data

encapsulated data.
Reception_valid_out - flag indication that the output is valid
new data.

Description

The data reception module contains 2 modules:

1. Aligner

2. Descrambler

OTN Framer Page 35

The module receives the raw data from the Transmitter and creates a valid data for
the Rx to de-encapsulate and send to the output.

The data_reception module forward the system input data to the aligner.
After aligner validates the input the module start a counter that counts until
4080 Bytes are received. The valid data send into the descrambler and
outputs as real data.

OTN Framer Page 36

Aligner

Inputs:

In_Frame (1b) - Flag indicates that the system is already busy in frame
processing. When not active (=0), FAS Detector is enabled.
In_vec (96b) - New input block containing 2 consecutive vectors of
48bit each.

Outputs:
Match (1b) - Flag indicates that a FAS has been found.
Offset (6b) - Offset of the current match which has been found in the
In_vec.

Description

The FAS Detector detects the FAS sequence which indicates the beginning of the
frame. The FAS is a 48b sequence: "F6F6F6282828".

OTN Framer Page 37

 FAS_Detector
Inputs:

en(1b) - Enable signal.

din(48b) - Data input : input vector for comparison.

Outputs:

Match (1b) - Flag indicates that FAS has been found.

The FAS Detector is an array of 48 6Bytes Comparators.

OTN Framer Page 38

Description

A single 6B Comparator is responsible for comparing 48bits input vector to the

special FAS sequence. A match flag is then raised to indicate that FAS has been
detected.
Having an array of 48 Comparators, the detector can detect the FAS Sequence
and the data offset within the received 48bits single clock cycle and align the
data accordingly through the entire Frame.

OTN Framer Page 39

 De-scrambler
Inputs:

clk (1b) - System clock.

nrst(1b) - System Reset, active low.
valid_in(1b) - Indicates the input data is valid.
data_in(48b) - The input block.
Rom_addr(12b) - The address of current XOR vector in ROM.

Outputs:

data_out(48b) - Output block.

valid_out(1b) - Indicates the output is valid.

Description

The descrambler works like the scrambler (in the Tx).

The concept is that XOR is associative action.

That means that: ( ) ( )

And ( ) and ( ) . So performing the scrambler XOR again

return the data to its original form.

OTN Framer Page 40

Data_arrange

Inputs:

Din_arrange(48b) the unscrambled encapsulated data.

Clk - system clock.
Data_handle_nrst- negative reset.
Da_en - enable.

Outputs:

Out_arrange1 (64b) - the output data for port number 1.

Out_arrange2 (64b) - the output data for port number 2.
Out_arrange3 (64b) - the output data for port number 3.
Out_arrange4 (64b) - the output data for port number 4.
Arrange_valid_out - the flag indicating a new valid output.

OTN Framer Page 41

Description

This is the main module of the Rx. The module is built from two parts:

1. Rearrange

In this part the module receives 48 bits input (din_arrange) and stores the
data in three memories (each one of them is 128bit wide):

Headers register this register holds all the headers data of a single
frame (128bit*4).
Payload data register this register holds an encapsulated data of a
single row (128bit*238).
FEC register this register holds the FEC data of a single row
(128bit*16).

This module has a complex Finite State Machine (FSM) (20 different stats). In
each state the machine receives 48bits and saves it in a temporary register
that holds 128bit. When the register is full, the machine moves the data to
one of the main memories.

2. De-encapsulate and route data

In this part, the module reads the routing data in the headers and de-
encapsulates the data in the payload data register. This module uses the
demux module. Data_arrange send to demux module, 128bit of data in 2 out
of 4 clocks (to try to simulate the input clock max ability (2.5Mbps) and
outputs every 4 clocks a 64bit output to the four ports.

OTN Framer Page 42

OTN Framer Page 43
Demux

Inputs:

Data_in (128bit) - the encapsulated data

Routing info - the port routing as read from the header
Clk - system clock
En - module enable
Nrst - active low reset

Outputs:

Out1 - the de-encapsulated data direct to port 1.

Out2 - the de-encapsulated data direct to port 2.
Out3 - the de-encapsulated data direct to port 3.
Out4 - the de-encapsulated data direct to port 4.

OTN Framer Page 44

OTN Framer Page 45
Hardware environment

XilinX Virtex-6 FPGA:

The Virtex-6 family provides the newest, most advanced features in the
FPGA market
Using the third-generation ASMBL (Advanced Silicon Modular Block)
column based architecture; the Virtex-6 family contains multiple distinct
sub-families. Each sub-family contains a different ratio of features to most
efficiently address the needs of a wide variety of advanced logic designs.
In addition to the high-performance logic fabric, Virtex-6 FPGAs contain
many built-in system-level blocks. These features allow logic designers to
build the highest levels of performance and functionality into their FPGA-
based systems.
Manufactured in 40 nm state-of-the art copper process technology, Virtex-6
FPGAs are a programmable alternative to custom ASIC technology.

Virtex-6 (XC6VLX240T) FPGA Feature Summary

Notes:
1. Each Virtex-6 FPGA slice contains four LUTs and eight flip-flops, only some slices can use their LUTs as
distributed RAM or SRLs.
2. Each DSP48E1 slice contains a 25 x 18 multiplier, an adder, and an accumulator.
3. Block RAMs are fundamentally 36 Kbits in size. Each block can also be used as two independent 18 Kb
blocks.
4. Each CMT contains two mixed-mode clock managers (MMCM).
5. This table lists individual Ethernet MACs per device.
6. Does not include configuration Bank 0.
7. This number does not include GTX or GTH transceivers.

OTN Framer Page 46

Software environment

XilinX ISE Design Suite 13.4:

Xilinx ISE is a software tool produced by Xilinx for synthesis and analysis of HDL
designs, which enables the developer to synthesize ("compile") their designs,
perform timing analysis, examine RTL diagrams, simulate a design's reaction to
different stimuli, and configure the target device with the programmer.
Xilinx Announces ISE Design Suite 13.4 in Jan. 18, 2012. This latest version provides
public access to the MicroBlaze Micro Controller System (MCS), new RX Margin
Analysis and debug capabilities for the 28nm 7 Series FPGAs and partial
reconfiguration support for the Artix-7 family and Virtex-7 XT devices.

New Features and improvements:

MicroBlaze MCS Simplifies Microcontroller-based Designs

MicroBlaze MCS, new to the Xilinx LogiCORE IP core offering, provides a
turnkey microcontroller solution to Xilinx customers. It includes the
MicroBlaze processor, local memory for program and data storage, as well as
tightly coupled GPIO, timers, interrupt controllers and other standard
peripherals.

New RX Margin Analysis Tool

The ChipScope Pro tool, available in the ISE 13.4 release, now provides an
RX Margin Analysis tool to help engineers optimize signal quality and lower
the bit error ratio (BER) on their designs. The RX Margin Analysis tool uses
2-dimensional statistical Eye Scan algorithms to interactively characterize
and optimize channel quality in real time, or during post-run processing.

4th Generation Partial Reconfiguration

Partial reconfiguration support for Artix-7 and Virtex-7 XT FPGAs is now
available in the PlanAhead tool. Partial reconfiguration dynamically
modifies logic blocks while the remaining logic operates without
interruption. This means designers can use Artix-7 and Virtex-7 XT devices to
build flexible systems that are able to swap functions and perform remote
updates while operational. Partial reconfiguration also allows designers to
reduce costs and design size by taking advantage of time-multiplexing that
ultimately leads to reduced board space and minimizes bitstream storage

OTN Framer Page 47

 because smaller, or fewer, devices can be utilized. Smaller and fewer devices
can also lead to reductions in system power, while swapping out power
hungry tasks can minimize the FPGA's dynamic power consumption. This
marks the first time Xilinx is offering partial reconfiguration for an entire
generation of FPGA families from low-cost to high-end.

Extends Support for 7 Series FPGAs

ISE Design Suite 13.4 is the first public release supporting the Artix-7 and
Virtex-7 XT FPGA families.
The Artix-7 FPGA delivers the lowest power and lowest cost to address high-
volume markets including: consumer 3DTV, multifunction printers, digital
SLR cameras, automotive driver assistance and infotainment, low power
handheld communications, medical endoscopes and handheld ultrasound
devices and industrial system monitor and control. With Agile Mixed Signal
(AMS) capabilities, included in all 28nm Xilinx devices, designers have the
industry's most flexible general purpose analog interface for customizing a
wide variety of applications, from simple control and sequencing to more
signal processing intensive tasks like linearization, calibration, and filtering.

Cadence Incisive Logic Simulator SimVision

SimVision is a unified graphical debugging environment for Cadence

simulators. SimVision main usage is to debug digital, analog, or mixed-signal
designs written in Verilog, SystemVerilog, VHDL, SystemC, or a
combination of those languages.

Coding language Verilog

Project's code is written in Verilog which is a Hardware Description

Language (HDL) used to model electronic systems. It is most commonly used
in the design and verification of digital circuits at the register-transfer level
of abstraction. It is also used in the verification of analog circuits and mixed-
signal circuits.

OTN Framer Page 48

Implementation Stages
Creating a Project:
Importing the Verilog source codes into ISE project navigator environment.
The environment creates a hierarchy according to the defined top module.

Creating IP cores:
IP cores are generic modules pre-implemented in the ISE development
environment. In the OTN Framer project there is a use in IP core generator in
order to create Read-Only-Memories (ROMS) (for scrambler and for input
images), FIFOs (for Tx and for transformation of the data from 64bits to 48bits)
and Random-Access-Memories (for output images).

Creating User Constrains File (UCF):

UCF file is a constrains file which contains board port mapping and timing
constrains. In The OTN Framer project, the reset signal is assigned to an
external switch on the board, and so is the routing signal which defines the
source- destination combination according to the switches state.

Creating ChipScope files (CDC):

The ChipScope is a core insertion tool for Xilinx boards.
This tool inserts logic analyzer, system analyzer, and virtual I/O low-profile
software cores directly into the design, allowing the view of any internal signal
or node, including embedded hard or soft processors. . Signals are captured in
the system at the speed of operation and brought out through the programming
interface, freeing up pins for the design. Captured signals are then displayed and
analyzed using the ChipScope Pro Analyzer tool.

Synthesizing final project and correcting syntax errors.

Burn the code on the FPGA

OTN Framer Page 49

Challenges and Solutions

1. Learning and understanding the OTN protocol

Learning and understanding the OTN protocol's goals and was a big
challenge in the project. The OTN standard is an innovative in
communication field and therefore it was a great challenge to understand its
purposes and to determine its place in the standard OSI model.

2. Choosing a suitable FPGA board

After understanding the performance requirements, we had to decide what is
the most appropriate FPGA board for implementing the design.
Since performance is a main goal in the OTN Framer project, Xilinx Virtex-6
FPGA was chosen. The large scale and great amount of resources allowed a
freedom in design and helped to achieve better results.

3. Extracting the Modules and Framer structure out of the OTN

recommendations
First, we had to understand the protocol very well and then we had to decide
what should be the structure of the framer implementation. After creation of
the modules structure and hierarchy, there is a need to decide of the
functionality and divide it between the different modules.

4. Problems and difficulties while using the Xilinx tools (ISE, FPGA)
While working on the Xilinx ISE, we had some difficulties. First we used the
SimVision in order to simulate the verilog code, and when the simulation
showed the expected results we started to simulate through ISE. The ISE
showed a lot of errors we didnt expected, and we had to change a lot of parts
on the code. After changing the code, we wanted to prepare the presentation.
the first step is burning the code on the Xilinx FPGA and the second step is to
demonstrate the OTN Framer operation.

OTN Framer Page 50

 We planned to use two screens - the first one, which represents the
transmitter, presents 4 images in the middle of the screen. The second screen
represents the receiver and presents the same images but their location
depends on the switches state. Each transformation of the switches state will
change the images in 10Gbps rate so the viewers wont even notice a small
delay.

Unfortunately, we had a lot of problems. We tried to implement it through

i2c, but we couldnt manage it. We had to compromise and present the
simulation results.

5. Saving Power and resources

We aimed to save power and resources in the OTN Framer code
implementation. We put a lot of attention to the registers we used, their size,
if we could optimize the code and save some clock cycled - we did it. An
example to power saving adding an enable signal to the modules can save a
lot of power in case there is no need of one/more modules.

OTN Framer Page 51

Future Ideas

Implement the FEC (Forward Error Correction)

In this project we didnt implement the FEC calculation due to the fact that in
the rate of 10Gbps the FEC is optional and not mandatory. We set the FEC
data to 0s in a register, and transmitted it in the frames. In the future, if the
FEC will be implemented, the calculation time must be taken into account.
For each 238Bytes of data that the receiver gets, 16Bytes of FEC are
calculated and when the FEC bytes of the whole 3808Bytes of data in each
frame row are calculated, the whole row can be transmitted. The
implementation may be very affective if the calculation can be done while
receiving the data dont wait for 238Bytes of data in order to calculate
16Bytes of FEC, start the calculation right in the beginning (after getting
x<238 Bytes).

Get traffic rate of 100Gbps

The OTN Framer is capable of achieving very high rates up to 100Gbps.
We get the rate of 100Gbps in this project, but if the hardware tools will be
adjusted for rates above 50Gbps, this protocol allows it. This implementation
will have to use the FEC calculation according to the protocol definition.

OTN Framer Page 52

Summary
The OTN Framer has a great ability of transporting data in high speed rates.
The OTN Framer protocol which defines the framer structure can manage data
transmission from four different sources to four different destinations with error
correction (FEC) and headers that adds details about the data and the routing.

Working on the OTN Framer project taught us a lot about the OTN Framer protocol
and how to work with hardware tools.
The implementation of the framer included a lot of deliberation about the decisions
we had to do - simplicity versus saving time and hardware resources, hardware
resources versus Savings time, power and Efficiency.
Most of the time we preferred to save power and energy and use some more
hardware resources such as registers, wires etc.

Building the OTN Framer is not complete, there are still some parts that werent
implemented (such as: FEC calculation), but we created the infrastructure for their
implementation and provided tools for more easy and convenient work.

OTN Framer Page 53

Bibliography

ITU-T G.709 tutorial:

http://www.itu.int/ITU-T/studygroups/com15/otn/OTNtutorial.pdf

An overview of ITU-T G.709:

http://cp.literature.agilent.com/litweb/pdf/5988-3655EN.pdf

Optical Transport Network & Optical Transport Module:

http://documents.exfo.com/appnotes/anote153-ang.pdf

A 10Gbps OTN Framer Implementation Targeting FPGA Devices:

http://www.inf.pucrs.br/~calazans/publications/2009_Reconfig_Guindani.pdf

xco2 product brief:

www.xelic.com/downloads/98/

ML605 User Guide:

http://www.xilinx.com/support/documentation/boards_and_kits/ug534.pdf

Virtex-6 FPGA Packaging & pinout spec:

http://www.xilinx.com/support/documentation/user_guides/ug385.pdf

Verilog tutorial:
http://www.ece.umd.edu/class/enee359a.S2008/verilog_tutorial.pdf

I2C Summary:
http://www.scribd.com/doc/32369877/I2C-Summary

OTN Framer Page 54