www.latticesemi.com
1
ip1032_01
Block Convolutional Encoder
September 2004
IP Data Sheet
2004 Lattice Semiconductor Corp. All Lattice trademarks, registered trademarks, patents, and disclaimers are as listed at www.latticesemi.com/legal. All other brand
or product names are trademarks or registered trademarks of their respective holders. The specifications and information herein are subject to change without notice.
The product described herein is subject to continuing development, and applicable specifications and information are subject to change without notice. Such specifica-
tions and information are provided in good faith; actual performance is not guaranteed, as it is dependent on many factors, including the user's system design.
Features
Compatible with the Following Standards:
IEEE 802.16, IEEE 802.16a, IEEE
802.11a,
3GPP, 3GPP2 and DVB-S
Supports Both Continuous and Block
Encoding
Supports Both Tail-biting and Zero-flushing
Convolutional Codes
Supports Both Internal and External
Zero-padding for Block Encoding
Supports Both Internal and External
Tail-adding for Block Encoding
Supports a Wide Range of Programmable
Code Rates (input_rate/output_rate), such
as 1/2, 1/3, 1/8, 6/10, 12/23
User-defined Generator Polynomials
Output Puncturing with User-
programmable Puncture Patterns
Variable Constraint Length from 3 to 9
Handshake Signals to Support Breaks in
Data Stream or Encoder-busy Conditions
General Description
Lattice's Block Convolutional Encoder IP core is a
parameterizable core for convolutional encoding of a
continuous or burst input data stream. The core allows
different code rates, constraint lengths and supports
puncturing. It can operate in continuous or block mode,
whichever is required by the channel. Either tail-biting or
zero-flushing convolutional codes can be generated
when the core works in the block mode. All these con-
figurable parameters, including operation mode, gener-
ator polynomials, puncturing block size and puncturing
pattern can be defined by the user to suit the needs of
the application. Lattice's Convolutional Encoder IP is
compatible with many networking and wireless stan-
dards that use convolutional encoding.
Figure 2 shows a digital transmit-receive system using
the Convolutional Encoder. The digital data stream
(such as voice, image or any packetized data) is first
convolutionally encoded, then modulated and finally
transmitted through a channel. The noise block in
Figure 2 represents channel noise added to the chan-
nel. The data received from the channel at the receiver
side is first demodulated and then decoded using a Vit-
erbi decoder. The decoded output is equivalent to the
original transmitted data stream.
Block Diagram
Figure 1. Block Convolutional Encoder Top-Level Diagram
dout
clk
rstn
outvalid
pbstart
rfi
Convolutional
Encoder
inpvalid
ibstart
ibend
din
rfib
obstart
obend
blklen
Lattice Semiconductor
Block Convolutional Encoder
2
Figure 2. Digital Transmit-Receive System
Convolutional Encoding
Convolutional encoding is a process of adding redundancy to a signal stream. Figure 3 shows an example of 1/2
rate convolutional encoding.
Figure 3. Convolutional Encoding Example
In this example, each input symbol has two corresponding output symbols, hence the encoding is called 1/2 rate
convolutional encoding. To generate the output, the encoder uses seven values of the input signal: one present and
six past. The set of past values of input data is called the "state". The number of input data values used to generate
the code is called the constraint length. In this case, the constraint length is 7. Each set of outputs is generated by
XORing a pattern of current and shifted values of input data. The patterns used to generate the coded output val-
ues can be expressed as binary strings called generator polynomials (GP). In this example, the generator polyno-
mials are 171 and 133 (in octal). The MSB of the generator polynomial corresponds to the input and the LSBs
correspond to the state as shown in Figure 3. A bit value of `1' in the generator polynomial represents a used XOR
bit and a value of `0' signifies an unused bit.
Punctured Codes and Depuncturing
After convolutional encoding, some of the encoded symbols can be selectively removed before transmission. This
process, called "puncturing", is a data compression method used to reduce the number of bits transmitted. Figure 4
shows an example of puncturing.
Convolutional
Encoder
Transmitted
Data Stream
Received
Data Stream
Viterbi
Decoder
Modulator
De-Modulator
Channel
Noise
reg
data out
data in
GP0 = 171 octal
GP1 = 133 octal
XOR
reg
reg
reg
reg
reg
Lattice Semiconductor
Block Convolutional Encoder
3
Figure 4. Puncturing Process
If puncturing is employed in the encoder, the decoder will have to "depuncture" the data before decoding. Depunc-
turing is done by inserting NULL symbols for the punctured symbols. NULL symbols are equidistant from both `0'
and `1'.
Continuous vs. Block Encoding
The convolutional encoding process can be applied on either continuous or blocks of input data. When the input
data stream is continuous, the encoder has to be configured to continuous mode. On the other hand, if the input
data stream is block based (or frame based), the core should be set for block encoding. The major difference
between the continuous and block encoding is the termination method that is used for block codes.
Zero-flushing vs. Tail-biting Mode
In the block encoding case, the code should be terminated correctly so that the decoding process can start from a
suitable initial state. Two block termination methods are supported by this IP: zero-flushing and tail-biting. In zero-
flushing mode, a series of zeros are added to the end of each block at the input of the convolutional encoder. In tail-
biting mode the last few bits of each block are used to initialize the state of the encoder, before encoding that block.
Both modes are widely used in various telecommunication standards.
Functional Description
A simplified implementation of the Lattice Block Convolutional Encoder IP core is shown in Figure 5. It consists of
an encoder, a puncture unit, a control unit and an input memory.
Figure 5. Block Convolutional Encoder Internal Architecture
i
0
i
1
i
2
i
3
i
4
i
5
i
6
a
0
b
0
a
1
a
2
a
3
a
4
a
5
a
6
b
1
b
2
b
3
b
4
b
5
b
6
a
0
b
0
b
1
a
2
a
3
b
3
b
4
1
1
0
1
1
0
a
5
Input Data
After Convolutional Coding
Puncture Pattern
Superimposed
Puncture Pattern
Final Punctured Output
a
0
b
0
a
1
a
2
a
3
a
4
a
5
a
6
b
1
b
2
b
3
b
4
b
5
b
6
dout
clk
rstn
outvalid
pbstart
rfi
Encoder
Puncture
Unit
inpvalid
ibstart
ibend
din
rfib
obstart
obend
Control Unit
clk
rstn
blklen
I
M
E
M
clk
rstn
Lattice Semiconductor
Block Convolutional Encoder
4
Encoder
The encoder module takes input data and performs convolutional encoding. The encoder uses generator polynomi-
als configured by the user. When punctured encoding is enabled, the encoder performs 1/2 rate encoding irrespec-
tive of the encoder rate. The puncture unit uses the 1/2 rate code to generate the appropriate user-programmed
rate.
The initial state of the encoder is related to the configuration settings of the IP core, as shown in the following table:
Table 1. Initial State of the Convolutional Encoder
Both zero-flushing and tail-biting for block encoding can be performed either inside or outside the IP core. If the out-
side mode is selected, it is the user's responsibility to append the information with the initial state. If the inside
mode is selected, the core will generate the zero-padding bits after the block for zero-flushing mode, or initialize the
state with the tail information before the block for tail-biting mode.
Puncture Unit
This unit performs data puncturing, as previously explained. The input is a two-channel data stream and the output
is a one-channel data stream. The unit is capable of performing puncturing of any block size and any code rate
supported by the core, and the puncture pattern is programmable.
Input Memory
For "tail-adding inside" mode, the core must store the entire message block and use the last K-1 bits to initialize the
registers. This is achieved by having an input memory module inside the core.
Control Unit
The control unit generates the handshake signals
obstart
,
obend
,
outvalid
,
rfi
,
rfib
and
pbstart
using
the input signals
inpvalid
,
ibstart
,
ibend
and the status of the encoder. The control unit also generates vari-
ous control signals required by the encoder and puncture unit for different continuous and block encoding
schemes.
Interfacing to the Block Convolutional Encoder Core
The puncturing-enabled convolutional encoder is a multi-rate system, with the output rate greater than the input
rate. The data rate mismatch between input and output can be managed by using the output signal
rfi
(ready for
input). The driving system should not apply an input to the encoder if the
rfi
output is low (if this is done, the data
will be ignored until
rfi
is high). When valid data is applied at the input
din
, input
inpvalid
must be asserted
high. Even if the
rfi
output is high, the driving system can blackout the input by pulling
inpvalid
low. The core
will optimize throughput by using up a portion of any user asserted blackout cycles as wait cycles (for data-rate
matching).
When the core works under block mode, the start and end of a block is defined either by
ibstart
and
ibend
sig-
nals, or by
ibstart
and the
blklen
input ports. In the latter case, the core has an internal counter to generate
the
ibend
signal counting from the input
ibstart
. However, if the tail-biting termination mode is selected and the
tail-adding is implemented inside, the block length is fixed during the IP configuration.This is because the whole
block of data must be stored in the core first, before encoding.
Configuration Setting
Initial State
Continuous encoding
0
Block encoding, zero-flushing code, zero added inside
0
Block encoding, zero-flushing code, zero added outside
Undefined
Block encoding, tail-biting code, tail added inside
Last K-1 samples in the block, where
K is the constraint length
Block encoding, tail-biting code, tail added outside
Undefined
Lattice Semiconductor
Block Convolutional Encoder
5
The output signal
pbstart
is asserted high to coincide with the start of a punctured block. This signal can be used
to synchronize the Viterbi decoder that is decoding the encoded stream.
The output control signal
outvalid
is high whenever the output is valid. This can be used as an enable signal to
latch the output to a memory.
For block encoding, the output signal
rfib
is asserted high to inform the input source that the core is ready to
accept the next block of data. The output control signals
obstart
and
obend
are used to inform the output desti-
nation of the start and end of each block.
Parameter Descriptions
Table 2. Block Convolutional Encoder Parameter Descriptions
Custom Core Configurations
For Block Convolutional Encoder core configurations not available in the Evaluation Package, please contact your
Lattice sales representative to request a custom configuration.
Related Information
For more information regarding core usage and design verification, refer to the
Block Convolutional Encoder User's
Guide,
available on the Lattice web site at www.latticesemi.com.
Parameter
Description
Constraint Length
Constraint length is equal to the number of input data values (present and past inputs) used to generate
the convolutional code. The value can be any integer from 3 to 9.
Input Rate
This defines the input symbol rate for the encoder. The input rate for non-punctured codes is always 1.
For punctured codes, the input rate can be any value from 2 to 12.
Output Rate
This defines the output symbol rate for the encoder. The output rate for non-punctured codes can be
any value from 2 to 8. For punctured codes, the output rate can be any value from 3 to 23 (k+1 to 2k-1,
where k is the input rate).
Generator
Polynomials
GP0, GP1, GP2, GP3, GP4, GP5, GP6 and GP7 are generator polynomials. For non-punctured encod-
ers, the number of generator polynomials is always equal to the output rate. For punctured encoders,
the number of generator polynomials is 2.
Punctured Data
Support
The encoder supports punctured or non-punctured data. For punctured data, the block size (punctured
block size) is equal to the input rate. The two puncture patterns PP0 and PP1 can be defined by the
user. The total number of 1's in both puncture patterns must equal the output rate.
Operation Mode
The user selects either continuous or block encoding mode.
Termination Mode
When the operation mode is "Block", the user can select either "zero-flushing" or "tail-biting" termination
mode.
Zero Padding Mode
When the zero flushing termination mode is used, the user can select either "inside" padding or "out-
side" padding. In "inside" padding, zeros are added to the data stream by the IP core itself. In the "out-
side" padding mode, the user needs to terminate a block with the appropriate number of zeros.
Tail Adding Mode
When tail biting termination mode is used, the user can select either "inside" adding or "outside" adding.
If the "inside" mode is chosen, the core stores the entire block of data and uses the last few data sam-
ples to initialize the state of the encoder, to result in a tail-biting code. If "outside" mode is chosen, the
user is expected to add the tail of the block to its beginning, and then apply the appended block at the
input of the encoder.
Block Length Options
For block encoding, the block length can be set in the following ways:
If "Read from Port" is selected, the user can set the block length through the
blklen
port. The width of
the
blklen
port can be from 4 to 9.
If both "Tail-Biting" and "Tail-Adding - Inside" options are selected for the core, then the user can set a
fixed number for the "Block Length". The block length is from 16 to 512. For a punctured encoder, the
number, (block length + constraint length - 1), must be a multiple of the input rate.
Lattice Semiconductor
Block Convolutional Encoder
6
Appendix for LatticeECPTM and LatticeECTM FPGAs
Table 3. Performance and Resource Utilization
1
Supplied Netlist Configurations
Table 4 shows the description of core configurations available in the standard evaluation package.
Table 4. Core Configurations for LatticeECP/EC FPGAs
The Ordering Part Number (OPN) for all configurations of this core on LatticeECP/EC is CONV-BLK-E2-N1.
Table 3 lists the netlist configurations that are available in the Evaluation Package for this core, which can be down-
loaded from the Lattice web site at www.latticesemi.com.
To load the preset parameters for this core, click on the "Load Parameters" button inside the IP Manager tool. Make
sure that you are looking for a file inside of this core's directory location. The Lattice Parameter Configuration files
(.lpc) are located inside this directory.
Parameter File
SLICEs
LUTs
Registers
I/Os
sysMEM
EBRs
f
MAX
(MHz)
Latency
conv_blk_e2_1_001.lpc
33
44
49
13
0
>300
9
conv_blk_e2_1_002.lpc
22
25
35
12
0
>250
4
conv_blk_e2_1_003.lpc
8
6
16
7
0
>350
3
1. Performance and utilization characteristics using LFEC20E-5F672C in Lattice's ispLEVER v.4.1 software. When using this IP core in a dif-
ferent density, package, or speed grade within the LatticeECP/EC family, performance may vary.
Parameter File
conv_blk_e2_1_001.lpc
conv_blk_e2_1_002.lpc
conv_blk_e2_1_003.lpc
Compatible Standards
IEEE 802.16
3GPP
3GPP2
802.11a
DVB-S
Constraint Length
3
9
7
Input Rate
2
1
1
Output Rate
3
2
2
Generator Polynomials
(Radix = Oct)
GP0=7
GP1=5
GP0=561
GP1=753
GP0=171
GP1=133
Puncture Pattern
PP0=11
PP1=10
n/a
n/a
Punctured Data Support
Punctured
Non-punctured
Non-punctured
Operation Mode
Block
Block
Continuous
Termination Mode
Tail-biting
Zero-flushing
n/a
Zero Padding Mode
n/a
Inside
n/a
Tail Adding Mode
Outside
n/a
n/a
PDF 
ZIP