Bar Ilan University
School of Engineering
VLSI Lab
OTN Framer
Netanel Gonen
Maayan Morali
Academic Advisor: Prof. Shmuel Wimer
Instructor: Mr. Moshe Doron
OTN Framer Page 2
Final Fourth Year Project Computer Engineering
Table of Content
Introduction……………………………………………...………………...……..……..4
Theoretical Background……………………………………………...……..…..…5
Goals………………………………………………………………..………….…..……..11
General Structure……………………………………………………..………….…12
TOP module……………………………………………………………………………13
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 3
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 4
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 5
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 6
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 “0”s or “1”s 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 7
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 8
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 9
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 10
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 11
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 12
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 project‘s presentation.
OTN Framer Page 13
General Structure
OTN Framer Page 14
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 15
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 16
OTN Framer Page 17
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 18
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 19
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 20
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 21
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 22
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 23
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 24
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 25
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 it’s 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 26
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 27
OutMux
Inputs:
Clk – System clock. nrst – System active low reset. en – System enable ScrambledData (48 bits)- Data in BeginNewFrame - Equals ‘1’ when it’s 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 it’s a new frame (BeginNewFrame = ‘1’), transmit FAS
Otherwise – transmit the scrambled data.
OTN Framer Page 28
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 29
( ) ( ) 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 30
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 31
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 32
Rx data flow
48bit from Tx
Fas received?Aligner
No
De-Scrambler
Yes
Data arrangment
Fec register
Headers
register
Temp data
register
output1 output2 output3 output4
OTN Framer Page 33
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 34
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 35
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 36
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 37
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 38
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 39
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 40
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 41
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 42
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 43
OTN Framer Page 44
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 45
OTN Framer Page 46
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 47
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 48
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 49
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 50
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 didn’t 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 51
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 won’t even notice a small
delay.
Unfortunately, we had a lot of problems. We tried to implement it through
i2c, but we couldn’t 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 52
Future Ideas
Implement the FEC (Forward Error Correction)
In this project we didn’t 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 0’s 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 – don’t 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 53
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 weren’t
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 54
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