Professional Documents
Culture Documents
OTN Framer Project Book
OTN Framer Project Book
School of Engineering
VLSI Lab
OTN Framer
Netanel Gonen
Maayan Morali
Table of Content
Introduction..........4
Theoretical Background.......5
Goals.......11
General Structure...12
TOP module13
Transmitter modules
TopTx.......17
DataPreparation........20
Tx_Mux.......22
FrameCreating.......24
OutMux.......26
Scrambler......27
The Receiver..........29
Receiver modules
Rx_top.....32
Aligner.....36
De-scrambler.......39
Data_arrange.......40
Demux.......43
Hardware environment..45
Software environment.46
Implementation Stages.48
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.
Headers first 16B of the row, contain data of routing, monitoring and
structure.
Data data from the sources.
FEC Forward Error Correction.
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.
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:
Overhead (16 bytes), Payload (3808 bytes) and FEC (256 bytes).
The OTN transmission does not follow the logic structure of the frame. It is
transmitted column by column as depicted in the Figure:
The OTN standard uses clock regeneration hardware on its receivers, therefore, long
sequences of 0s or 1s can compromise the clock regeneration process and
should be avoided. To avoid those long sequences, OTN transmitters use a
scrambling process on the OTN frames before transmission.
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.
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.
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.
GCC0:
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
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
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.
Inputs
Outputs
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.
1. TopTx
2. rx_top
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
Tx module is divided to several smaller modules. Each one of them has specific
function.
TopTx
Inputs:
Outputs:
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.
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.
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 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
Inputs:
Outputs:
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.
Inputs:
Outputs:
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).
The states:
Inputs:
Outputs:
Description:
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.
Inputs:
Outputs:
Description:
Inputs:
Outputs:
Description:
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;
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.
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).
48bit from Tx
No
Aligner Fas received?
Yes
De-Scrambler
Fec register
Data arrangment
Headers
register
Temp data
register
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:
The rx_top modules receives 48bit input from the user, output 4*64 bit ports
and announce that a new data is ready.
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.
Inputs:
Outputs:
Description
2. Descrambler
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.
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".
Outputs:
Outputs:
Description
Inputs:
Outputs:
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.
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.
Inputs:
Outputs:
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.
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.
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.
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).
4. Problems and difficulties while using the Xilinx tools (ISE, FPGA)
While working on the Xilinx ISE, we had some difficulties. First we used the
SimVision in order to simulate the verilog code, and when the simulation
showed the expected results we started to simulate through ISE. The ISE
showed a lot of errors we didnt expected, and we had to change a lot of parts
on the code. After changing the code, we wanted to prepare the presentation.
the first step is burning the code on the Xilinx FPGA and the second step is to
demonstrate the OTN Framer operation.
Working on the OTN Framer project taught us a lot about the OTN Framer protocol
and how to work with hardware tools.
The implementation of the framer included a lot of deliberation about the decisions
we had to do - simplicity versus saving time and hardware resources, hardware
resources versus Savings time, power and Efficiency.
Most of the time we preferred to save power and energy and use some more
hardware resources such as registers, wires etc.
Building the OTN Framer is not complete, there are still some parts that werent
implemented (such as: FEC calculation), but we created the infrastructure for their
implementation and provided tools for more easy and convenient work.
Verilog tutorial:
http://www.ece.umd.edu/class/enee359a.S2008/verilog_tutorial.pdf
I2C Summary:
http://www.scribd.com/doc/32369877/I2C-Summary