bar ilan university school of engineering vlsi...

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

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

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

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

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

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

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

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

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

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

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

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

General Structure

OTN Framer

TOP module

Inputs

Din1 (48bit) - System input from port1.




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.




Valid_out - Flag indicating a new data is in the output.

OTN Framer

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

OTN Framer

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

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

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

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

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

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

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

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

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

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

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

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

( ) ( ) 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

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

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

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

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.




Rx_valid_out - flag, indicating new valid output data.

OTN Framer

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

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

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

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

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

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

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

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.




Arrange_valid_out - the flag indicating a new valid output.

OTN Framer

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

OTN Framer

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.




OTN Framer

OTN Framer

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

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

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

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

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

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

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

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

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

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

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

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

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

http://www.xelic.com/downloads/98/

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

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

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

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

bar ilan university school of engineering vlsi...

Documents