OTN FRAMER - BIUengineering.biu.ac.il/files/engineering/shared/Project_Book_Orlev... · 1 הסדנהל ס"היב םיבשחמ תסדנהל הדבעמה OTN FRAMER Groundwork for phase

1

ביה"ס להנדסה

הנדסת מחשביםהמעבדה ל

OTN FRAMER Groundwork for phase 2

גולן אורלב

יגאל קרלינסקי

מחשביםפרויקט שנה ד' לקראת תואר ראשון בהנדסת

מר משה דורון מנחה:

פרופ' שמואל וימר אחראי אקדמי:

, תשרי תשע"ב1122אוקטובר

2

Table of Content

Introduction 4

Goals 5

Method Description 6

Theoretical Background 7

Project’s Design

Introduction 10

General Structure 11

Framer’s Elements

Aligner

Top 12

FAS Detector 15

Comparator 6B 18

Scrambler

Top 19

ROM 22

Counter 12 bit 23

Payload & Header Extractor

Top 24

OverHead RAM 27

TimeSlot RAM 28

Top 29

Development Environment

Hardware Environment 31

Software Environment 33

3

Simulation Method, Results & Analysis

Method & Guidlines 35

Results & Analysis

Aligner 36

Scrambler 39

Payload & Header Extractor 43

Top Module 45

Challenges and Solutions 46

Summary 49

Conclusions 50

Future Ideas 51

Appendixes 52

Bibliography 53

4

Project Introduction

In this project, we design and implement an OTN processing unit called Framer.

In general, the OTN protocol is a new network protocol for transmitting data over

optical infrastructure.

The Framer, in this project, designed to operate at the client side. Thus, it's main

operation is to analyze and process OTN multiframes received at the network end

(Client Side). The client side (our project implements receiving traffic only. RX)

is responsible for receiving OTN Multiframes, processing and extracting data

according to the OTN protocol.

The OTN multiframe consists of 6 major parts:

1. Frame Alignment Signal (FAS) – A special sequence of bits indicates the

beginning of the Multiframe.

2. Header – OTN protocol header.

3. 4 Time Slots – Data is divided to 4 time slots that can later be extracted to 4

different data frames.

The Framer's main elements that will be designed and implemented are:

1. Aligner – Detects a special sequence called "FAS" that indicates beginning of

a Frame. Responsible also for aligning the frame according to the offset that

was found on the frame arrival.

2. Scrambler – The OTN multiframe is scrambled (will be explain later).

The scrambler is responsible for descramble the multiframe at the client side.

3. Payload & Header Extraction – The Multiframe, as described above, consists

of 4 smaller data frames. This element is responsible for extracting the data

out of the Multiframe along with the OTN Header.

All the elements are designed in Verilog ©, simulated by Cadence © SimVision ® and

implemented on Xilinx® FPGA evaluation board.

5

Project Goals

1. 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.

2. Implementation of the OTN framer design on FPGA Development Board.

Performing all design and implementation steps:

RTL design, Elaboration, Synthesis and FPGA burn.

6

Project Method Description

Comprehensive and thorough study of the OTN protocol.

Studying the FPGA Development boards available and choosing the most

suitable one among them.

Designing a suitable Test Bench environment for validation and testing.

To meet these speed rate demands, all of the framer's main elements will

be designed in hardware rather than in software.

All elements will be assembled together and implemented on FPGA

development board.

Final product must hold predetermined data rates at specific clock rates.

Final product functionality and credibility will be validated and tested.

7

Theoretical Background Introduction

Due to the large scale globalization process activities nowadays, information

exchange has become a critical issue, requiring the elaboration of faster, flexible, less

expensive and reliable computer networks.

The migration of network technologies to faster protocols (Gigabit Ethernet and

10 Gb Ethernet) forces the utilization of optical fiber links in both local (LAN) and

metropolitan (MAN) network backbones.

To meet the increasing demand for increased bandwidth using optical fiber links, and

to support 2.5 Gb, 10 Gb and 40 Gb broadband services, a new optical transport

network layer was developed, the Optical Transport Network (OTN) [1].

OTN is the only standard capable of transporting 10GbE LAN PHY entirely.

Different from the time multiplexed SONET-SDH (TDM), the OTN protocol is

multiplexed in wavelength (WDM), 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 128 bytes in 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.

8

The OTN interface must have the ability to carry signals from different types of

clients, as shown in the Figure 1.

The OTN frame is composed of 16 lines of 255 bytes, and divided to three main

blocks:

Overhead (16 bytes), Payload (3808 bytes, in 238 columns) and FEC (256 bytes in 16

columns).

The OTN transmission does not follow the logic structure of the frame. It is

transmitted column by column as depicted in Figure 2.

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.

Figure 2 – The OTN Frame transmission sequence

Figure 1 – Distinct signal sources transported over OTN

9

The scrambling process operates conceptually as a Linear Feedback Shift Register

(LFSR), using the generating polynomial .

The output of the scrambling process (Figure 3) is added to each bit of the

multiframe.

Figure 3 – Conceptual RTL implementation of the OTN scrambling process.

Recommendation G.709 defines the OTN multiframe (Figure 4), 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.

Figure 4 – Structure of the OTN 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.

11

Project's Design Introduction

The Framer consists of 4 major elements:

1. Aligner - The frame aligner module is responsible to identify the FAS

(Frame Alignment Sequence) sequence. The FAS includes the 6 first bytes of a

multiframe.

2. Scrambler - The scrambler module is responsible to scramble the data the

framer transmits, using a LFSR (Linear Feedback Shift Register) pseudo-

random data generation technique. This technique is used to avoid the

transmission of long sequences of “0”s or “1”s.

The scrambling process operates on the overall OTN G.709 multi-frame, with

the exception of the FAS field. The unscrambling functionality is the same of

the scrambling, because this process is symmetric.

3. FEC - The forward error correction (FEC) module uses the Reed-Solomon (RS)

error correction method to introduce redundant information into the OTN

frame. The receiver employs this additional information to search and correct

errors, which may appear due to the transmission process.

The FEC element is not implemented in this project according to projects

guidelines agreed with the instructor and due to its complexity.

4. Payload & Header extractor – As explained earlier, the multiframe consists of

4 smaller frames each carries data payload. Thus, the Payload & Header

extractor module is responsible for extracting the OTN header and the 4

different frames and to store them for later processing.

11

Project's Design – General Structure

OTN OPTICAL INTERFACERX

Deserializer

Aligner

Descrambler

Payload ExtractorHeader Extractor

Serializer

CLIENT INTERFACETX

FRAMER GENERAL STRUCTURE

FPGA

Figure 5 – Framer General Structure

12

Project's Design – Framers Elements Aligner – TOP

1. Developed Aligner Architecture

Figure 6 – Developed Aligner Architecture

Aligner

clk

nrst

Counter_en

Valid_out

EOC

Din [47:0]

dout [47:0]In_Vec

Match

Offset [5:0]

In_Frame

Fas Detector

In_Frame

In_Vec [95:0]

Match

Offset [5:0]

Comp_6B

match

en

Din [47:0]

Comp_6B

match

en

Din [47:0]

Comp_6B

match

en

Din [47:0]

[47:0]

[48:1]]

[95:47]

Co

mp

Re

sult

13

Project's Design – Framers Elements Aligner - TOP

2. General Description

The Aligner is responsible for aligning the data according to the offset found by

the FAS detector. Once FAS has been found, the aligned data is sent to the

output.

3. Input Signals

clk(1b) - System clock.

nrst(1b) - System Reset, active low.

EOC(1b) - Counter generated End-Of-Count signal - last 48 data bits of the

frame.

din(48b) - Data input - raw data from input ports.

4. Output Signals

dout(48b) - Data output - Aligned 48 vector.

valid_out(1b) - Data out valid flag.

counter_en(1b) - Counter enable control signal. This indicates that a FAS has

been discovered and that the system is in a middle of frame processing.

5. Elements in use

FAS Detector

Comparator 6B (6 Bytes = 48bits)

14

Project's Design – Framers Elements Aligner - TOP

6. Data Flow Functionality Diagram

Awaiting FAS

Awaiting FAS

Aligning Input

Vectors

FAS is found

End of count occured

Enabling Counter Determining Alignment Offset

FAS not found

Disabling Counter

Aligner Data Flow

Figure 7 – Aligner TOP Data Flow Functionality Diagram

15

Project's Design – Framers Elements Aligner – FAS Detector

1. Developed FAS Detector Architecture

Fas Detector

In_Frame

In_Vec [95:0]

Match

Offset [5:0]

Comp_6B

match

en

Din [47:0]

Comp_6B

match

en

Din [47:0]

Comp_6B

match

en

Din [47:0]

[47:0]

[48:1]]

[95:47]

Co

mp

Resu

lt

Figure 8 – Developed Fas Detector Architecture

16

Project's Design – Framers Elements Aligner – FAS Detector


The FAS Detector detects the FAS sequence which indicates the beginning of the

frame. The FAS is a 48b sequence: "F8F8F8262626"

3. Input Signals

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.

4. Output Signals

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.

5. Elements in use

Comparator 6B

17

Project's Design – Framers Elements

Aligner – FAS Detector


Awaiting Not In Frame

Signal

Awaiting Not In Frame

Signal

Searching FAS

Sequence

Not In Frame

Match is Found

Still In Frame

FAS Detector Data Flow

FAS is: F6F6F6282828

Saving Offset for current FAS match

FAS not found

Figure 9 –Fas Detector Data Flow Functionality Diagram

18


Aligner – Comparator 6B

1. Developed Comparator 6B Architecture

Comp_6B

match

en

Din [47:0]

Figure 10 – Developed Comparator 6B Architecture


The Comparator 6B is responsible for comparing a 48b input vector to the special

FAS sequence. A match flag is then raised to indicate that FAS has been detected.

3. Input Signals

en(1b) - Enable signal.

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

4. Output Signals

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

19


Scrambler – TOP

1. Developed Scrambler Architecture

Scrambler

clk

nrst

Valid_out

Valid_in

Rom_Addr [11:0]

dout [47:0]

Data_in [47:0]

ROM

douta [47:0]

ena

addra [11:0]

Mem [47:0] [0:2719]

Scrambler_ROM.list

ROM_out

XOR

Figure 11 –Developed Scrambler Architecture

21


Scrambler – TOP


The Scrambler receives input blocks of 48 bit and outputs

scrambled/descrambled data (48b). Scramble operation prevents long sequences

of ones and zeros in the frame. Scrambling achieved by performing XOR

operation between frame bits and predefined sequence 128k in size.

This sequence is stored in ROM module.

3. Input Signals

clk (1b) - System clock.


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.

4. Output Signals

data_out(48b) - Output block.

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

5. Elements in use

ROM

21


Scrambler – TOP


Awaiting

Valid Data

Input

Awaiting

Valid Data

InputDeScrambling

Data in

Data in Valid

Data in not Valid

Data in not Valid

Scrambler Data Flow

Figure 12 –Scrambler TOP Data Flow Functionality Diagram

22


Scrambler – ROM

1. Developed ROM Architecture

ROM

douta [47:0]

ena

addra [11:0]

Mem [47:0] [0:2719]

Scrambler_ROM.list

Figure 13 –Developed ROM Architecture


Latch type memory. Outputs data when enable is set to one.

As previously explained, the scrambler is responsible to scramble the data the

framer transmits, using an LFSR pseudo-random data generation technique.

To meet the delay constraints, a memory block with the contents of the

generated LFSR values is used, replacing the traditional LFSR structure. In this

new architecture, all possible polynomial scrambled sequences are pre-stored in

a memory block (ROM).

3. Input Signals

ena (1b) - ROM read enable control signal.

addra (1b) - ROM address bus input.

4. Output Signals

data_out(48b) - ROM output data bus.

23


Counter 12 bit

1. Developed Counter 12 bit Architecture

Counter_12b

clk

nrst

EOC

count_out [11:0]

en

Figure 14 – Developed Counter 12 bit Architecture


This module is the main counter of the system. Once FAS is found the counter

receives enable flag and starts counting. With each 48b vector input vector at

every clock the counter is raised.

The total OTN frame contains 2719 such vectors (48b). Thus, this counter counts

to 2718 (0-2718) and then sends EOC signal.

3. Input Signals



en(1b) - Enable signal. Received once a FAS is found

4. Output Signals

EOC (1b) - Counter generated End-Of-Count signal - last 48 data bits of the

frame. This flag is raised at count value of 2718.

count_out (12b) - The current value of the counter.

24


Payload & Header Extractor - TOP

1. Developed Payload & Header Extractor – TOP Architecture

Figure 15 – Developed Payload & Header Extractor – TOP Architecture

Payload_Header_EX

clk

nrst

Valid_in

Din [47:0]

Counter [11:0]

Ts1.txt

Ts2.txt

Ts3.txt

Ts4.txt

OH.txt

RAM_OH

clk

Mem [7:0] [0:127]

Nrst

en1 – en6

din1 – din6[7:0]

fh [31:0]

RAM_TS1

clk

Mem [7:0] [0:8191]

Nrst

en1

din1 [7:0]

fh [31:0]

din2 [7:0]

en2

RAM_TS2

clk

Mem [7:0] [0:8191]

Nrst

en1

din1 [7:0]

fh [31:0]

din2 [7:0]

en2

RAM_TS3

clk

Mem [7:0] [0:8191]

Nrst

en1

din1 [7:0]

fh [31:0]

din2 [7:0]

en2

RAM_TS4

clk

Mem [7:0] [0:8191]

Nrst

en1

din1 [7:0]

fh [31:0]

din2 [7:0]

en2

25




This module is responsible for extracting the 4 timeslots data and overhead data

from the OTN multiframe. The extraction is made according to the counter's

input.

3. Input Signals



Valid_in(1b) - Data input valid signal.

data_in(48b) - Data input vector.

counter(12b) - Counter value.

4. Output Signals

There is no output for this module. The extracted 4 data frames and the header

are stored in designated RAM's.

For simulation purpose, the data is also flushed into 5 file handles.

5. Elements In Use

RAM_OH

RAM_TS

26




Data in not Valid

Payload & Header Extractor Data Flow

Clock && Valid Data in

State 1:OH_din1=data_in [47:40]OH_din2=data_in [39:32]OH_din3=data_in [31:24]OH_din4=data_in [23:16]OH_din5=data_in [15:8]OH_din6=data_in [7:0]

State 2:TS1_din1=data_in[15:8]TS2_din1=data_in[7:0]OH_din1=data_in[47:40]OH_din2=data_in[39:32]OH_din3=data_in[31:24]OH_din4=data_in[23:16]

State 3:TS1_din1=data_in[31:24]TS2_din1=data_in[23:16]TS3_din1=data_in[47:40]TS3_din2=data_in[15:8]TS4_din1=data_in[39:32]TS4_din2=data_in[7:0]


State 4:TS1_din1=data_in[47:40]TS1_din2=data_in[15:8]TS2_din1=data_in[39:32]TS2_din2=data_in[7:0]TS3_din1=data_in[31:24]TS4_din1=data_in[23:16]


State 0:OH_din1=data_in [47:40]OH_din2=data_in [39:32]OH_din3=data_in [31:24]OH_din4=data_in [23:16]OH_din5=data_in [15:8]OH_din6=data_in [7:0]

Clock && Valid Data in Clock && Valid Data in && End Of Line


Figure 16 – Payload & Header Extractor – TOP Data Flow Functionality Diagram

27


Payload & Header Extractor – RAM OH

1. Developed Payload & Header Extractor RAM OH Architecture

RAM_OH

clk

Mem [7:0] [0:127]

Nrst

en1 – en6

din1 – din6[7:0]

fh [31:0]

Figure 17 – Developed Payload & Header Extractor – RAM OverHead Architecture


This module is a 6 ports RAM memory, designed to contain the overhead part of

the frame.

3. Input Signals



En1 - 6(1b) – Enable signals.

Din1-6(48b) - Data input vectors.

Fh (32b) - File handler for flushing the RAM content into a file.

4. Output Signals

There is no output for this module. The extracted header is stored in designated

memory.

For simulation purpose, the data is also flushed into a file handle (fh).

28


Payload & Header Extractor – RAM TS

1. Developed Payload & Header Extractor Ram TS Architecture

RAM_TS

clk

Mem [7:0] [0:8191]

Nrst

en1

din1 [7:0]

fh [31:0]

din2 [7:0]

en2

Figure 18 – Developed Payload & Header Extractor – RAM TimeSlot Architecture


This module is a 2 ports RAM memory, designed to contain the Time Slots part

of the frame.

3. Input Signals



En1 - 2(1b) – Enable signals.

Din1-2(48b) - Data input vectors.

Fh (32b) - File handler for flushing the RAM content into a file.

4. Output Signals

There is no output for this module. The extracted Time Slot is stored in

designated memory.

For simulation purpose, the data is also flushed into a file handle (fh).

29

F

i

g

u

r

e

1

9

–

D

e

v

e

l

o

p

e

d

T

O

P

A

r

c

Pro

ject

's D

esi

gn

– F

ram

ers

Ele

me

nts

TOP

1.

Dev

elo

ped

TO

P A

rch

itec

ture

31


TOP


This is the TOP element of the framer. It combines all the framers elements into

the final top design of the project.

3. Input Signals



Din(48b) - Data input vectors.

4. Output Signals

There is no output for this module. The extracted 4 data frames and the header

are stored in designated RAM's inside the Payload & Header extractor.

For simulation purpose, the data is also flushed into 5 file handles.

5. Elements In Use

Aligner

Counter 12 bit

Scrambler


31

Project's Development Environment

Hardware Environment

1. XilinX ML605 Evaluation Board:

Overview

The ML605 board enables hardware and software developers to create or evaluate

designs targeting the Virtex®-6 XC6VLX240T-1FFG1156 FPGA.

The ML605 provides board features common to many embedded processing

systems. Some commonly used features include: a DDR3 SODIMM memory, an 8-

lane PCI Express® interface, a tri-mode Ethernet PHY, general purpose I/O, and a

UART. Additional user desired features can be added through mezzanine cards

attached to the onboard high-speed VITA-57 FPGA Mezzanine Connector (FMC)

high pin count (HPC) expansion connector, or the onboard VITA-57 FMC low pin

count (LPC) connector.

Block Diagram

Figure 20 – XilinX ML605 Evaluation Board – Block Diagram

32


Hardware Environment

2. XilinX © Virtex-6 © FPGA:

Overview

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.

33


Software Environment

1. XilinX © ISE Design Suite 12.3

Overview

Xilinx introduced ISE Design Suite 12.3. ISE Design Suite 12.3 supports Intellectual

Property (IP) cores that meet the AMBA 4 AXI4 specification for interconnecting

functional blocks in System-on-Chip (SoC) design. The latest version of ISE Design

Suite features productivity enhancements to the PlanAhead Design and Analysis

cockpit, and Intelligent Clock Gating support for reducing dynamic power

consumption in Virtex-6 FPGA designs.

Xilinx ISE Design Suite 12.3 Highlights

Expanded PlanAhead RTL Design, Development and Analysis Cockpit

The ISE Design Suite software’s PlanAhead design tool offers a seamless “push-

button” flow in addition to an advanced visualization and analysis flow. The

PlanAhead tool’s cockpit also includes Project Management, Synthesis, CORE

Generator integration, Floorplanning, Place-and-Route, ChipScope Pro tool

integration and Bitstream generation. The entire Xilinx IP catalog, including AXI4

protocol IP cores, is directly accessible and searchable from the same design cockpit.

Intelligent Clock Gating Support for Virtex-6 FPGAs

With ISE Design Suite v12.3, Intelligent Clock Gating supports the high-performance

Virtex-6 FPGA families. Intelligent clock-gating technology features fully automated

analysis and fine-grain (logic slice) optimization capabilities specifically developed to

reduce the number of transitions.

The technology can reduce dynamic power consumption by as much as 30% by

using a series of unique algorithms to detect sequential elements (‘transitions’) within

each FPGA logic slice that do not change downstream logic and interconnect when

toggled. The software generates clock-enable logic that automatically shuts down the

unnecessary activity at the logic slice level to accumulate power savings without

having to shut off an entire clock network.

34


Software Environment

2. 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.

Project's code is written in Verilog, defining Hardware Behavioral and

simulated by SimVision ©.

3. Microsoft Visual C++

The Multiframe Creator is a unique program build for this project.

The Multiframe Creator builds an OTN Multiframe by taking 4 files and

combining them as the payload section of the Multiframe. It also wraps the

Payload with an OTN header and FAS.

This program was written in Microsoft Visual C++ and attached as an

appendix to this project's book.

35


Simulation Method

As previously detailed, the project's source code was simulated by Cadence Incisive

Logic Simulator – SimVision.

A testbench code has been developed for each module separately and for the final

TOP module as well.

We tested each module using wave signal analysis and compared with expected

results.

Simulation guidelines

The Framer's elements and functionality is simulated according to these guidelines:

1. Aligner

Detecting a Frame Alignment Sequence + raising a valid out flag.

Enabling the counter.

Aligning the incoming vectors from FAS detection till End-Of-Count

received.

2. Scrambler

Storing the pre-calculated LFSR's (The special vectors which the input

data is being "XORed" with) in a special ROM.

Validate that the output of the XOR operation is correct.

3. Payload & Header Extractor

Inject a pre-made example Multiframe (Created by an external program).

Verify that data is split into the correct TimeSlot or Header's RAM.

Flush the content of the RAM's and compare with expected results.

4. Top

Combine all the elements together and validate results

36


Simulation Results & Analysis

Aligner

Detecting a Frame Alignment Sequence + raising a valid out flag

In this part we inject several data input vectors (48 bit each). The FAS

(special Frame Alignment Sequence) is located inside those vectors and

we wish to check that it is detected.

The input vectors for this section are:

48'h11F8F8262625

48'h11F8F82F6F6F Fas is marked in red.

48'h628282811111

Simulation Result:

nrst signal is raised – the Aligner starts working.

FAS is located between these two vectors (F6F6F6282828).

Match flag is raised as the FAS is detected – Success.

Data out valid signal is raised in the next clock to indicate the output

is an aligned valid data.

4

3

2

1

1 2 3 4

37



Aligner

Enabling the counter

The OTN protocol specifies the OTN Multiframe exact size in bits.

Thus, there is an exact amount of 48 bit vectors with in an OTN

Multiframe as specified in the OTN protocol.

Once a FAS is found, The Aligner sends an enable signal to the counter to

start counting the input vectors.

Simulation Result:

Match flag raised – Indicates a FAS is found.

Once a FAS is found the counter enable signal is raised.

Counter starts counting (The count_out signal is the output of the

external counter element – The Counter).

3

2

1

1 2 3

38



Aligner

Aligning the incoming vectors

Since the data input is sampled by a clock and not necessarily at the

transmitted rate, the data input may be received unaligned.

Therefore, once a FAS is found, the aligning process begins.

The offset of the Frame is determined at the detection of the FAS and

saved till the end of the current Multiframe process. All the input vectors

received after the FAS are being aligned by that same offset.

The alignment process is finished once an End-Of-Count (EOC) signal is

received from the counter, indicating that all of the Multiframe's vectors

received.

Simulation Result:

FAS is located between these two vectors (F6F6F6282828).

Input vectors are unaligned and need alignment.

Aligned vectors at output. (According to the detected offset).

For simulation purpose, we set the counter limit to 4 for this part.

The EOC signal is raised once the counter reached the limit.

4

3

2

1

1 2 3 4

39



Scrambler

Storing the pre-calculated LFSR's in a special ROM

The scrambler module is responsible to scramble the data the framer

transmits, using an LFSR pseudo-random data generation technique. This

technique is used to avoid the transmission of long sequences of “0”s or

“1”s.

A linear feedback shift register (LFSR) is a shift register whose input bit is

a linear function of its previous state. The initial value of the LFSR is called

the seed, and because the operation of the register is deterministic, the

stream of values produced by the register is completely determined by its

current (or previous) state. Likewise, because the register has a finite

number of possible states, it must eventually enter a repeating cycle.

However, an LFSR with a well-chosen feedback function can produce a

sequence of bits which appears random and which has a very long cycle.

The scrambling process operates on the overall OTN G.709 multi-frame,

with the exception of the FAS field. The unscrambling functionality is the

same of the scrambling, because this process is symmetric.

The OTN G.709 defines following generating polynomial:

1 + x + x3 + x12 + x16

Basic implementation of scrambler, XORing the input data with the LFSR

sequence is as follows:

http://en.wikipedia.org/wiki/Shift_register

http://en.wikipedia.org/wiki/Linear#Boolean_functions

41

However, this implementation fails to meet our projects time constrains

as there's 1 clock delay for each bit. To meet those constrains, a memory

block with the contents of the generated LFSR values is used, replacing the

traditional LFSR structure. In this new architecture, all possible polynomial

scrambled sequences are stored in one memory block, and since the OTN

standard polynomial order is 16, there are 65535 (2^16) pseudorandom

bits .

Din

Dout

Each clock, 48 bits are scrambled/descrambled.

The ROM contains in 2719 blocks. Each block is 48 bit long as we work at 48bit architecture.

Frame length in OTN protocol is 2720*48=130560 bits. Sequence length is 2^16=65535 bits. Therefore, we store in our ROM memory a little bit less than 2 periods of LFSR sequence.

We received the needed sequence by writing a small Matlab program which simulates LFSR operation

LFSR

Sequence

XOR

41

Simulation Result:

The LFSR's are stored in ROM inside the Scrambler module.

There are 2720 LFSR's to match the 2720 vectors of 48 bit inside a

Multiframe.

42



Scrambler

Validate that the output of the XOR operation is correct

As previously described, each input vector is XORed with the matches

LFSR from the ROM.

If we are looking at the client side, the data is received scrambled, thus,

operating the scrambler process on it will de-scramble the data, and

hence the data will be translated to the original data sent by the

transmitter.

Simulation Result:

The counter's output is used as the ROM in address.

Example input vector FFFFFFFFFFFF and the matches ROM vector

FFFF4E9105D2.

The data output is the XOR of these two vectors:

FFFFFFFFFFFF ^ FFFF4E9105D2 = 0000B16EFA2D.

3

2

1

1 2 3

43




Inject a pre-made example Multiframe

As this project implements the client side of the framer, the input of the

framer consists of OTN Multiframes coming from the Network side to the

client side.

As previously described, the OTN Multiframe consists of 4 data frames as

the payload section and is wrapped by the OTN Header and the initiating

FAS.

In order to simulate Multiframe processing and the extraction of 4 data

frames and header, an example Multiframe was built externally by a third

party program (also written by us).

The program creates 4 data files, scrambles the data, adding the

scrambled data according to the correct time slots, adding the OTN

header and plants the initial FAS.

With each clock cycle, the simulation reads 48 bits from the Multiframe

and sends them as an input vector to the data in port of the Aligner.

Simulation Result:

The multiframe is stored in the test bench for simulation purpose.

44




Verify that data is split into the correct TimeSlot or Header's RAM

As described in the previous section, the payload of the Multiframe is

extracted to 4 different RAM's. The extraction is made according to time

slots in which each clock cycle is considered as a time slot. Each data

frame has its own time slot (there are 4 time slots total) and every clock

cycle the correct data ram is chosen to store the input data vector.

The header is also extracted to designated RAM.

For simulation purpose, the content of all 4 RAMS and of header's RAM is

flushed to files in order to examine results.

Simulation Result:

Content of RAMS is flushed into files for examination.

45



Top Module

Combine all the elements together and validate results

The TOP module combines all the above elements into one module which

is in fact the final product.

To simulate functionality of the top, the simulation reads, at every clock

cycle, 48bit vector from the pre-created Multiframe.

The vector passes through all the design steps as described below:

1. FAS detection and alignment at the Aligner module.

2. Descrambling at the Scrambler Module

3. Payload & Header extraction at The Payload & Header extractor.

Once all steps are done, the vector is inserted to the correct RAM as

previously described.

The content of all RAMS is flushed to separate files and compared with

the original data that was building the Multiframe.

46

Challenges and Solutions

1. Understanding the OTN protocol and technology

One of the main challenges in our project was to understand OTN protocol's

goals and objectives. 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.

In addition, no one from the academic staff could help us or even check

whether our understanding of the protocol is correct.

2. Extracting the main functions out of the OTN recommendations

The only document given to us was ITU-T G.709 recommendation spec as the

protocol itself is not yet developed by any organization. We had to work very

hard in order to understand which functions we should implement in our

project. We had to determine what should be implemented in the hardware

and what in the software.

The main difficulty wasn't the "How?" but the "What?"

3. Choosing a suitable FPGA board to stand high performance demands

After understanding the performance requirements for this project, we faced

the mission of choosing an appropriate FPGA board on which the design will

be implemented. With no previous experience in hardware design nor in the

world of FPGA implementation this was a great challenge at start.

The Xilinx Virtex-6 FPGA was chosen thanks to its large scale and great

performance. The large scale and great amount of resources gave as design

freedom to achieve better performance and speed without having to worry

about lack of resources.

47

4. Learning and experiencing FPGA based hardware development

Coming to use the Xilinx FPGA board we faced lack of basic knowledge in

FPGA design and implementation. Moreover, no previous knowledge were to

be found in the university due to the fact that this board is new and never

been used in the VLSI lab.

In order to deal with these difficulties, we performed several meetings with

Xilinx technical engineers both frontal and telephonic.

5. Cutting down power

With today's main demand for low power consumption, we were obligated to

power conservation and efficiency during the entire project.

As an example for that principle, all of our modules have an enable signal in

order to verify that there is no wasted power where it is not needed.

Example 1:

Fas Detector – Each of the 48 comparators that are used by the FAS Detector

has an enable signal. When we are already in frame processing, they are not

needed and therefor sit still until new frame detection is required.

Example 2:

Aligner – Only when the counter enable signal is up, the data is forwarded to

the dout port (in order to conserve power consumption due to data

forwarding over the data bus). Even though there is a "valid out" flag that

indicates whether the data out is valid or not.

48

6. High speed demands and delay constrains

In real time devices such as communication processor, time constrain is

extremely crucial. In several cases during our work we had to look through

the more simple design in order to meet those constrains.

Example 1:

FAS Detector module - uses 48 12Byte parallel comparators in order to

discover the FAS.

Example 2:

Scrambler module – the scrambling sequence was pre-stored in ROM block in

order to save time. In both cases we choose to spend more hardware in order

to gain time. The ML605 board allows us to do so.

7. How to verify and simulate the final product

The best way to test a network processor is by using a Traffic Generator

(SmartBit, Ixia etc.). Since we don’t have one, we had to think about an

alternative way to prove our project works properly.

We designed a simulation that takes a ROM memory as an input and writes

the output to 5 RAM memories. The input ROM contains scrambled

multiframe which we prepared using c program. The output RAMs simulates

5 different channels – 4 time slots, and payload overhead, transferred to CPU

for further processing.

49

Summary

In this project we were exposed to new technology and hardware applications.

The OTN protocol is very unique and innovative both in high speed traffic rates and

in combining two operational network protocol (DWDM & Sonet/SDH).

The OTN is not yet a final protocol but a guidelines and recommendations for future

applications.

Out of the non-final tutorial we were manage to extract the OTN Framer's main

functions and set the guidelines for implementation.

All the framers main elements were developed and design in HDL to be implemented

on hardware only. By doing that, we were able to meet the very strict and high

speed demand of the OTN protocol.

Thanks to the large scale and speed of the Xilinx® FPGA Virtex-6® board, we had

more design flexibility and were able to construct large scaled modules working in

parallel.

Although we spent a lot of time trying to understand OTN requirements our project

can't be considered as a fully operating network processor. Our work is more like a

solution proposal for several functions described by the ITU-T G.709 specification

document.

51

Conclusions

This work showed that FPGA is effective in creating complex systems with tight performance requirements. Besides the complexity of the design, and the strict rules defined in the OTN definition, timing closure was one of the major design challenges. Simple modules, such as the frame aligner, required a VHDL gate level description, with several parallel stages.

In addition, due to the high-speed incoming stream, and high data rates,

several modules had to be replicated, increasing the final FPGA occupation.

Scrambling and descrambling logic can easily be implemented using very little logic resources in the Virtex6 family devices thanks to the pre-stored scrambling sequences data.

This system is currently a functional prototype. The final design was fully

simulated and tested in the VLSI lab by Cadence® Incisive SimVision® tools.

As a future work, the system can be extended to include other client

elements such as the assembler and transmitter of OTN multiframes.

This project was based on a tutorial for Optical Transport Network standards and their applications. This is only recommendations rather than standard. Its objective was to provide the future engineers that will continue this project with a document that forms the basis for understanding OTN Framer’s main applications.

51

Future Ideas

1. Design and implement the transmitter side of the Framer

Our project implemented the client side of the framer - the receiver side.

The client side receives Multiframes from the network, descrambles and

extracts the 4 data frames and the header.

For complete Framer's functionality, the transmitter side should also be

designed and implemented.

The transmitter side constructs the Multiframe out of 4 data sources, wraps

the payload with an OTN header and adds the FAS.

2. Integration with OTN phase 1

The second phase of the framer deals with the kernel software design.

This is in fact the Embedded Processor of the Framer that analyzes the OTN

header of the Multiframe, makes the appropriate changes and wraps the new

Multiframe for resending to the next destination.

3. Achieving processing rate of 100Gbps

As we described, the OTN protocol defines guidelines for achieving traffic

rate of 100 Gigabit per second.

This could not be tested nor simulated with the limited traffic generators

resources we had in the lab.

A nice future goal would be to achieve the desired theoretical rate of

100Gbps.

For that, an evaluation FPGA Board, having the new, faster 28nm Virtex7 and

a very fast on-board Transceivers (28Gbps), is needed.

52

Appendixes

OTN Protocol Theory

A. ITU-T G.709 OTN RFC

B. OTN Tutorial

Xilinx Hardware Platform

C. Xilinx FPGA – ML605 Product Brief

D. Virtex6 Family Overview

E. Virtex6 Data Sheet - DC and Switching

Verilog Source Code

F. All elements Verilog source codes and test benches – RAR file

53

Bibliography

1. ITU-T “G.870: Terms and definitions for optical transport networks (OTN)” - Apr. 2009. http://www.itu.int/rec/TREC-G.870-200803-I/en

2. Kocialski, C. and Harwood, J., “A Primer on Digital Wrappers for Optical Transport Networks”

Vesta Corporation, 2000

3. Vissers, M. “Optical Transport Network & Optical Transport Module“– Apr. 2009. http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport /OTN /g709-intro-v2.ppt

4. Lucent Technologies. OTN Processor Device Requirements. Nurnberg, 2002.

5. ML605 Reference Design User Guide

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

6. Getting Started with the Xilinx Virtex-6 FPGA ML605 Evaluation Kit


7. SONET and OTN Scramblers/Descramblers.

Author: Nick Sawyer

www.xilinx.com

http://www.itu.int/rec/TREC-G.870-200803-I/en

http://ties.itu.ch/ftp/public/itu-t/tsg15opticaltransport%20/OTN%20/g709-intro-v2.ppt



http://www.xilinx.com/

Documents

OTN FRAMER - BIUengineering.biu.ac.il/files/engineering/shared/Project_Book_Orlev... · 1 הסדנהל ס"היב םיבשחמ תסדנהל הדבעמה OTN FRAMER Groundwork for phase