| |
 |
1.1 Executive Summary
The key value of Forward Error Correction (FEC) technology
is that it allows the receiver of a corrupted message the
potential to correct the message without referring to the
transmitter of the message. The contribution of Constellation's
FEC Framework not an advancement in the theory of FEC, but
rather a revolutionary advancement in implementation. It is
this ease of implementation, which substantially reduces development
risk, cuts time from project development, and results in a
gain of product quality.
This white paper describes a method of firmware implementation
of FEC, with specific focus to use, methods and schemes of
evaluation and demonstration appropriate to firmware systems.
While the technology described herein is agnostic with respect
to implementation, some example implementations are mentioned
in the context of the discussion.
This White Paper is of interest to engineers and managers
contemplating issues regarding data communications where noise
injection results in discrepancies between transmitted data
and received data (also know as "data errors").
A document wide assumption is that the interest of the reader
in forward error correction involves use of this technology
in communications systems such as Radio Frequency (RF) or
Light Wave (LW) links.
Additional white papers which describe this
technology are available. Click here
for more information, or for sales and licensing of this technology.
2. The Forward Error Correction Framework
The Constellation Data Systems, Forward Error Correction Framework
can be implemented using one of the following environments:
1. Software (Application / Kernel Mode Device Driver / System
Level) environment.
2. Firmware (Microprocessor based embedded code) environment.
3. Field Programmable Gate Array (FPGA) digital logic environment.
Initial implementations of the FEC Framework are built around
FEC paradigms appropriate to small and medium duty firmware
based systems, such as BCH or Reed-Solomon codes.
2.1 High / Low Data Rate, Single Bit Data Corruption
A special case of binary Bose-Chaudhuri-Hocquenghem ("BCH")
code, which have the ability to discover and correct single
bit errors, with a minimum of overhead in the "v"
(see Chapter 3) data path.
2.2 Bursty Noise, Low Data Rate
Reed-Solomon ("RS") code have the
reputation to provide excellent forward error correction capability
environments characterized by consecutive runs of bit errors.
2.3 High Data Rate, Bursty Noise
Recursive and Block TURBO codes have in recent years demonstrated
suitability in this environment, at the expense of additional
firmware resources consumed (in terms of memory and consumed
CPU execution) on the target system.This white paper addresses
the use of the FEC framework, implemented using certain RS
and BCH coding methods, in the firmware environment.
Future implementations of the FEC Framework shall be built
around a variety of ECC codes, including TURBO. Future implementations
are anticipated to span the Software, Firmware and FPGA environments
with a common IP core architecture.
3. FEC/ECC in Communications Overview
Forward Error Correction (FEC) is an art where
errors in a transmitted data payload may be corrected by a receiver
without referring to the transmitter for re-transmission or correction.
FEC codes are an example of Error Correcting Codes ("ECC"),
wherein it is possible for Transmitted Data ("TX") stream,
corrupted by the influence of Additive White Gausian Noise ("AWGN"),
to be reconstructed by the receiver such that the transmit stream
equals the receive stream ("RX"). Consider the following
Data Flow Diagram:
Figure 1 - FEC / ECC Data Flow Diagram
In this diagram, the stream from the Data Domain
is rendered from TX data into RX data, through interfaces to the
FEC / ECC Domain. Those interfaces are described at the firmware
level as the FEC Firmware Programming Interface (FECFPI). The
FECFPI is described in overview in Appendix C.
When FEC technology is properly applied and the effects of
AWGN in RF / LW Domain are within range, then the TX data will
equal the RX data. Detailed domain descriptions may be seen
in Appendix B.
4. FEC Firmware Demonstration Platform
The FEC Firmware Demonstration Platform (FFDP)
consists of a CPU board built hypothetically around the eZ80 Family
Platform and a mounted eZ80 F92 CPU module (Zilog PC: 99C0858-001
and 99C0857-001). This implementation processes asynchronous serial
data at its outside most points (P2/P3 and COM1/COM2), the data
content is separated from the framing (by the De-Frame and Reframe
methods, as well as by the RF-LW Link Simulation). Bit Synchronous
implementations are also possible in other configurations. In
other words, the demonstration is applied to the data content
and is opaque to the data framing.
Figure 2 - FEC / ECC Firmware Demonstration
The FEC / ECC Firmware is developed using the interfaces of
the FECFPI (see Appendix C), thus allowing for rapid integration
with the customer's environments. The net effect is that that
the FFDP demonstration provides the confidence that the FEC
Framework enables the gains in productivity, lowers development
cost, and decreases time on the schedule. The FFDP demonstration
also validates the corresponding reduction in risk.
Other implementations may be ordered built around other CPU
architectures such as those sold by Cypress, Texas Instruments,
Zilog, Intel, Motorola, etc.
The FEC Framework provides the firmware developer
contemplating an FEC implantation with a reduced risk, reduced
development time, and reduced cost option. The FEC Firmware Demonstration
Platform (FFDP) allows both management and engineering to proceed
with confidence. The selectable option of IP deliverables (see
Appendix A) provides the customer with a growth path to ever more
capable and cost effective implementations.
Appendix A Scenarios of Deliverables
Prospective customers may choose from a variety of deliverables.
IP components are licensed on a non-exclusive basis.
FFDP Test Procedure Document - This document describes the
test procedures which form the basis for validation techniques
of the FEC Firmware Demonstration Platform (FFDP) function.
FFDP Test Report - This document describes the results of
testing performed using the FFDP Test Procedure.
FEC FPI Programmers Guide and Reference - This document describes
the firmware interfaces of the FEC Firmware Programming Interface
(FPI).
FEC Implementation Theory of Operation - This document describes
source code level description of Reed-Solomon ECC or BCH coding
theory as applied to the firmware of the FEC Framework.
FECF Module Descriptions and Build Procedures - This document
describes procedures used by developers and engineers to convert
to FECF source code into its run or link time modules.
FECF Implementation Analysis - This document implementation
specific document describes the performance of the FECF within
customer's specific RF/LW and AWGN environment.
FFDP Site Setup and Demonstration - This deliverable consists
of setup and demonstration of the FEC Firmware Demonstration
Platform at a site selectable by the customer.
FECF Firmware Modules - These IP deliverables would consist
of either source and/or object code modules.
Appendix B - Domain Descriptions
The Data Domain illustrated in Figure 1 assumes
a somewhat industry standard byte wise (8 bit) data presentation.
The De-Frame method converts these bytes of "TX" data
into a bit stream named "u". The De-Frame method may,
in certain implementations, also involve stripping certain framing
information from the data stream, such as start and stop bits
in asynchronous serial framing, or re-ordering of bits such
that the Least Significant Bits (LSB) of "TX" is presented
to "u" before the next Most Significant Bits (MSB)
of "TX". In synchronous environments ( HDLC / SDLC,
for example) , the "De-Frame"/"Reframe"
methods may either inject the "bit stuffing" overhead,
or remove the overhead as dictated by the implementation.
Analogously, the Reframe method coverts "~u"
into the proper LSB / MSB format, and when applicable also restores
other serial framing information.
The FEC / ECC domain consists of an Encoder and a Decoder
method. The Encoder method converts the "u" bit
stream into an expanded "v" bit stream. The expansion
is necessary to carry the burden of the Error Correct Code.
The Decoder method converts the "r" data stream
(as received from the RF Domain) into the "~u" data
stream. When the affects of AWGN are within tolerance, the
"u" data stream should equal the "~u"
data stream.
RF/LW Domain
The RF/LW Domain consists of the TX Modulation method, the
Radio Frequency or Light Wave Link itself, as well as the
RX De-Modulation method. These methods move (transmit) the
"v" data stream, and in the process render the "r"
data stream. The "r" stream is the "v"
stream affected by AWGN, as well as errors introduced by the
RX De-Modulation method.
In some implementations the RF/LW Domain is totally opaque
to the FEC / ECC Domain. In other implementation, such as
some QAM-64/32/16 implementations, there can be a performance
improvement resulting from adroit interpretation of "v"
and "r" in context of face of the attributes of
the connected FEC / ECC Domain.
Appendix C - FEC Firmware Programming Interface
FecRsEncode ( ) Function
FecRsDecode ( ) Function
FecBchEncode ( ) Function
FecBchDecode ( ) Function
FecRsSetFieldGeneratorPolynomial ( ) Function
FecBchSetFieldGeneratorPolynomial ( ) Function
FecSetMode ( ) Function
FecGetMode ( ) Function
FecSetStatusBlock ( ) Function
FecSetStatusBlock ( ) Function
FecSetDecodeExecption ( ) Function
FecSetSymbolsAndFrames ( ) Function
Appendix D - Index of Acronyms / Abbreviations
k........................Number
of input symbols per frame
n........................Number of output symbols per frame
t........................Time
r........................De-Modulated Receive Data stream
u........................Transmit Data Stream
v........................Output of the FEC / ECC Encoder
x........................Modulated v data.
y........................Data Received from the RF Link
AWGN.....................Additive
White Gausian Noise
BPS......................Bits per Second ("baud")
CDS......................Constellation Data Systems, Inc.
CPU......................Central Processing Unit
DFD......................Data Flow Diagram
ECC......................Error Correcting Code
FFDP.....................FEC Firmware Demonstration Platform
FPI......................Firmware Programming Interface
HDLC.....................High-level Data Link Control
IP.......................Intellectual Property
LSB......................Least Significant Bit or Byte
LW.......................Light Wave
MSB......................Most Significant Bit or Byte
QAM......................Quadrature Amplitude Modulation
RAM......................Random Access Memory
RF.......................Radio Frequency
RS.......................Reed-Solomon
RX.......................Receive
SDLC.....................Synchronous Data Link Control
TBD......................To Be Determined
TLA......................Three Letter Acronym
TX.......................Transmit
|
|
