IPUG32 - Block Viterbi Decoder IP Core User`s Guide

Block Viterbi Decoder User’s Guide
June 2010
IPUG32_02.7
Table of Contents
Chapter 1. Introduction .......................................................................................................................... 4
Quick Facts ........................................................................................................................................................... 4
Features ................................................................................................................................................................ 6
Chapter 2. Functional Description ........................................................................................................ 7
General Description .............................................................................................................................................. 7
Convolutional Encoding ............................................................................................................................... 7
Punctured Codes and Depuncturing ............................................................................................................ 8
Viterbi Decoding........................................................................................................................................... 8
Functional Description........................................................................................................................................... 9
Branch Metric Unit (BMU) ............................................................................................................................ 9
Add, Compare, and Select Unit (ACS)....................................................................................................... 10
Traceback Unit (TBU) ................................................................................................................................ 10
Memory (MEM) .......................................................................................................................................... 10
Memory Management Unit (MMU)............................................................................................................. 10
Bit Error Rate Monitor (BER)...................................................................................................................... 10
Other Modules............................................................................................................................................ 10
Configuring the Block Viterbi Decoder ................................................................................................................ 10
Puncture Settings....................................................................................................................................... 10
Continuous and Block Decoding ................................................................................................................ 10
Termination Modes .................................................................................................................................... 11
Number of Tracebacks and Traceback Length .......................................................................................... 11
Block Length .............................................................................................................................................. 11
Data Type................................................................................................................................................... 12
Signal Descriptions ............................................................................................................................................. 12
Interfacing with the Block Viterbi Decoder .......................................................................................................... 14
Timing Diagrams ................................................................................................................................................. 15
Core Configurations ............................................................................................................................................ 17
Chapter 3. Parameter Settings ............................................................................................................ 18
Primary Options Tab ........................................................................................................................................... 19
Primary Options ......................................................................................................................................... 19
Operation Mode ......................................................................................................................................... 19
Block Options ............................................................................................................................................. 19
Traceback Length ...................................................................................................................................... 20
Puncturing .................................................................................................................................................. 20
Puncture Settings....................................................................................................................................... 20
Advanced Options Tab........................................................................................................................................ 20
Generator Polynomials............................................................................................................................... 20
GP0, GP1, GP2, GP3, GP4, GP5, GP6..................................................................................................... 21
Implementation Method.............................................................................................................................. 21
Inputs ......................................................................................................................................................... 21
BER (Bit Error Rate)................................................................................................................................... 21
Chapter 4. IP Core Generation............................................................................................................. 22
Licensing the IP Core.......................................................................................................................................... 22
Getting Started .................................................................................................................................................... 22
IPexpress-Created Files and Top Level Directory Structure............................................................................... 25
Instantiating the Core .......................................................................................................................................... 26
Running Functional Simulation ........................................................................................................................... 26
Synthesizing and Implementing the Core in a Top-Level Design ....................................................................... 26
Hardware Evaluation........................................................................................................................................... 27
© 2010 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.
IPUG32_02.7, June 2010
2
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Table of Contents
Enabling Hardware Evaluation in Diamond:............................................................................................... 27
Enabling Hardware Evaluation in ispLEVER:............................................................................................. 27
Updating/Regenerating the IP Core .................................................................................................................... 27
Regenerating an IP Core in Diamond ........................................................................................................ 27
Regenerating an IP Core in ispLEVER ...................................................................................................... 28
Chapter 5. Support Resources ............................................................................................................ 29
Lattice Technical Support.................................................................................................................................... 29
Online Forums............................................................................................................................................ 29
Telephone Support Hotline ........................................................................................................................ 29
E-mail Support ........................................................................................................................................... 29
Local Support ............................................................................................................................................. 29
Internet ....................................................................................................................................................... 29
References.......................................................................................................................................................... 29
LatticeEC/ECP ........................................................................................................................................... 29
LatticeECP2M ............................................................................................................................................ 30
LatticeECP3 ............................................................................................................................................... 30
LatticeSC/M................................................................................................................................................ 30
LatticeXP.................................................................................................................................................... 30
LatticeXP2.................................................................................................................................................. 30
Revision History .................................................................................................................................................. 30
Appendix A. Resource Utilization ....................................................................................................... 31
LatticeECP and LatticeEC FPGAs ...................................................................................................................... 31
LatticeECP2 FPGAs............................................................................................................................................ 31
Ordering Part Number................................................................................................................................ 32
LatticeECP2M FPGAs......................................................................................................................................... 32
Ordering Part Number................................................................................................................................ 32
LatticeECP3 FPGAs............................................................................................................................................ 32
Ordering Part Number................................................................................................................................ 32
LatticeSC and LatticeSCM FPGAs ..................................................................................................................... 33
Ordering Part Number................................................................................................................................ 33
LatticeXP FPGAs ................................................................................................................................................ 33
Ordering Part Number................................................................................................................................ 33
LatticeXP2 FPGAs .............................................................................................................................................. 34
Ordering Part Number................................................................................................................................ 34
IPUG32_02.7, June 2010
3
Block Viterbi Decoder User’s Guide
Chapter 1:
Introduction
The Block Viterbi Decoder IP core is a parameterizable Viterbi Decoder for decoding different combinations of convolutionally encoded sequences. The decoder supports various code rates, constraint lengths, and generator polynomials. It also allows soft-decision decoding and is capable of decoding punctured codes. The core can operate in
continuous or block modes, whichever is required by the channel. Either Tail Biting or Zero Flushing convolutional
codes can be decoded in the block mode. All the configurable parameters, including operation mode, generator
polynomials, punctured block size, and puncture pattern can be defined by the user to suit the needs of their application. The code rate and puncture pattern can also be changed dynamically through input ports during the operation of the decoder. Lattice’s Block Viterbi Decoder IP is compatible with many networking and wireless standards
that use different methods of convolutional encoding at the encoder.
Quick Facts
Table 1-1 through Table 1-4 give quick facts about the Block Viterbi Decoder IP core for LatticeEC™, LatticeECP™, LatticeECP2™, LatticeECP2M™, LatticeECP3™, LattticeSC™, LatticeSCM™, LatticeXP™, and
LatticeXP2™, devices.
Table 1-1. Block Viterbi Decoder IP Core for LatticeEC/ECP/XP Devices Quick Facts
Block Viterbi IP Configuration
IEEE
802.16
2004- SC
PHY
3GPP
LFEC1E
LFECP6E
LFXP3C
LFEC10E
LFECP10E
LFXP10C
FPGA Families Supported
Core
Requirements
Minimal Device Needed
LUTs
sysMEM EBRs
Registers
Synthesis
500
9950
LFEC3E
LFECP6E
LFXP3C
LFEC6E
LFECP6E
LFXP6C
2600
2750
3300
2
16
4
4
4
250
3200
900
1050
1200
Diamond® 1.0 or ispLEVER® 8.1
Synopsys® Synplify® Pro for Lattice D-2009.12L-1
Aldec® Active-HDL® 8.2 Lattice Edition
Simulation
IPUG32_02.7, June 2010
LFEC3E
LFECP6E
LFXP3C
LFEC20E-5F672C/ LFECP20E-5F672C/ LFXP20E-5F256C
Lattice Implementation
Design Tool
Support
IEEE 802.162004-OFDM
PHY (fixed
puncturing)
LatticeEC/ECP/XP
Targeted Device
Resource
Utilization
DVB-S
IEEE
802.11A
IEEE 802.162004-OFDM
PHY
(dynamic
puncturing)
Mentor Graphics® ModelSim® SE 6.3F
4
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Introduction
Table 1-2. Block Viterbi Decoder IP Core for LatticeECP2/ECP2M/XP2 Devices Quick Facts
Block Viterbi IP Configuration
IEEE 802.16
2004- SC
PHY
3GPP
FPGA Families Supported
Core
Requirements
Minimal Device Needed
LUTs
LFE2-6E
LFE2M20E
LFXP2-5E
LFE2-12E
LFE2M20E
LFXP2-17E
LFE2-6E
LFE2M20E
LFXP2-5E
LFE2-6E
LFE2M20E
LFXP2-5E
500
11800
3050
3250
3500
2
16
4
4
4
250
3200
900
1050
1200
Lattice Implementation
Design Tool
Support
LFE2-6E
LFE2M20
E
LFXP2-5E
LFE2-50E-7F484C/ LFE2M35E-7F672C/ LFXP2-30E-7F484C
sysMEM EBRs
Registers
IEEE 802.162004-OFDM
PHY (fixed
puncturing)
LatticeECP2/ECP2M/XP2
Targeted Device
Resource
Utilization
DVB-S
IEEE
802.11A
IEEE 802.162004-OFDM
PHY
(dynamic
puncturing)
Diamond 1.0 or ispLEVER 8.1
Synopsys Synplify Pro for Lattice D-2009.12L-1
Synthesis
Aldec Active-HDL 8.2 Lattice Edition
Simulation
Mentor Graphics ModelSim SE 6.3F
Table 1-3. Block Viterbi Decoder IP Core for LatticeSC/SCM Devices Quick Facts
Block Viterbi IP Configuration
IEEE
802.16
2004- SC
PHY
Core
Requirements
FPGA Families Supported
LUTs
sysMEM EBRs
Registers
LFSC3GA15E/LFSCM3GA15EP1
LFSC3GA25E-7F900C/ LFSCM3GA25EP1-7F900C
450
9450
Synthesis
2650
3250
2
16
4
4
4
3400
900
1050
1200
Diamond 1.0 or ispLEVER 8.1
Synopsys Synplify Pro for Lattice D-2009.12L-1
Aldec Active-HDL 8.2 Lattice Edition
Simulation
IPUG32_02.7, June 2010
2450
250
Lattice Implementation
Design Tool
Support
IEEE
802.162004-OFDM
PHY (fixed
puncturing)
LatticeSC/SCM
Minimal Device Needed
Targeted Device
Resource
Utilization
3GPP
DVB-S
IEEE
802.11A
IEEE 802.162004-OFDM
PHY
(dynamic
puncturing)
Mentor Graphics ModelSim SE 6.3F
5
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Introduction
Table 1-4. Block Viterbi Decoder IP Core for LatticeECP3 Devices Quick Facts
Block Viterbi IP Configuration
IEEE
802.16
2004- SC
PHY
Core
Requirements
3GPP
FPGA Families Supported
Minimal Device Needed
LUTs
sysMEM EBRs
Registers
LFE3-35EA
LFE3-95E-8FN672CES
500
11750
3050
3200
3500
2
16
4
4
4
250
3200
900
1050
1200
Lattice Implementation
Design Tool
Support
IEEE
802.162004-OFDM
PHY (fixed
puncturing)
LatticeECP3
Targeted Device
Resource
Utilization
DVB-S
IEEE
802.11A
IEEE 802.162004-OFDM
PHY
(dynamic
puncturing)
Diamond 1.0 or ispLEVER 8.1
Synopsys Synplify Pro for Lattice D-2009.12L-1
Synthesis
Aldec Active-HDL 8.2 Lattice Edition
Simulation
Mentor Graphics ModelSim SE 6.3F
Features
• Compatible with IEEE 802.16-2004 SC PHY/ OFDM PHY, IEEEE802.11a, 3GPP, 3GPP2, and DVB standards
• Supports multiple code rates: 1/2, 1/3, ... 1/7 for non-punctured codes, 2/3, 3/4, ..., 12/13 for punctured codes,
and from m/(m+1) to m/(2m-1), where m is from 1 to 12, for dynamic punctured codes
• Variable constraint length from 3 to 9
• Supports dynamically variable code rates and puncture patterns
• Dynamic BER estimation option
• One-clock synchronous design
• Hard or parameterizable soft decision decoding. Hard and soft decision for non-punctured codes and soft decision for punctured codes
• Fully parallel or hybrid implementations. For a hybrid implementation, the degree of parallelism is parameterizable
• Parameterizable trace-back length
• Signed and unsigned representations for soft decision data
• Supports parameterized puncturing patterns
• Supports both continuous and block data input
• Supports both Tail Biting and Zero Flushing block convolutional codes
• Supports both one and two traceback schemes to cater to different coding scenarios
IPUG32_02.7, June 2010
6
Block Viterbi Decoder User’s Guide
Chapter 2:
Functional Description
This chapter provides a functional description of the Block Viterbi Decoder IP core.
Figure 2-1 shows the interface diagram for Block Viterbi Decoder. The diagram shows all of the available ports for
the IP. It should be noted that not all the I/O ports are available for all configurations.
Figure 2-1. Block Viterbi Decoder Interface Diagram
din0
din1
din2
din3
din4
din5
din6
clk
rstn
pbstart
ibstart
ibend
ppset
inrate
outrate
pp0
pp1
dout
outvalid
obvalid
ber
bervalid
Block
Viterbi Decoder
rfib
General Description
Viterbi decoding is an efficient algorithm for decoding convolutionally encoded sequences corrupted by channel
noise back to the original sequence. A digital transmit-receive system shown in Figure 2-2 uses a Viterbi decoder
for decoding the convolutionally encoded data. The digital data stream (e.g., voice, image, or any packetized data)
is encoded, modulated, and transmitted through a wired or wireless channel. A “noise” block connected to the
channel symbolically denotes the channel noise. The data received from the channel at the receiver side is first
demodulated and then decoded using the Viterbi decoder. The decoded output is equivalent to the transmitted digital data stream.
Figure 2-2. Digital Transmit-Receive System
Transmitted
Data Stream
Convolutional
Encoder
Modulator
Channel
Demodulator
Block Viterbi
Decoder
Received
Data Stream
Noise
Convolutional Encoding
Figure 2-3 shows an example of convolutional encoding. 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” of the encoder. The number of input data values used to generate the code is called the constraint length
(K). In this case, the constraint length is 7. Each set of outputs is generated by XOR-ing a pattern of current and
shifted values of input data. The patterns used to generate the coded output value can be expressed as binary
strings called generator polynomials (GP). In this example, the generator polynomials are 171 and 133 (in octal).
IPUG32_02.7, June 2010
7
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
The MSB of the generator polynomial corresponds to the input and the LSBs correspond to the state as shown in
Figure 2-3. A bit value of ‘1’ in the generator polynomial represents a used bit and a value of ‘0’ signifies an unused
bit.
Figure 2-3. Convolutional Encoding
GP0 = 171 octal
XOR
data in
reg
reg
reg
reg
reg
reg
data out
GP1 = 133 octal
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 2-4 shows an example of the puncturing process.
Figure 2-4. Puncturing Process
After convolutional coding
Input data
i0
i1
i2
i3
a0 a1 a2 a3 a4 a5 a6
i4
i5
i6
Puncture pattern
b0 b1 b2 b3 b4 b5 b6
Puncture pattern
superimposed
Final punctured output
1
0
1
a0 a1 a2 a3 a4 a5 a6
1
1
0
b0 b1 b2 b3 b4 b5 b6
a0 b0 b1 a2 a3 b3 b4 a5
If puncturing is employed in the encoder, the decoder will have to “depuncture” the data before decoding. Depuncturing is done by inserting NULL symbols for the punctured symbols. NULL symbols are equidistant from both ‘0’
and ‘1’. A pair of binary strings, called a “puncture pattern,” is used to identify punctured symbols. A “1” in a pattern
means the corresponding symbol was not punctured in the encoder, while a “0” means the symbol has been punctured.
Viterbi Decoding
The convolutional encoding mentioned above can be considered as a series of state transitions for every input
symbol. The input and the resulting state transitions can be shown in a special state transition diagram called a
“trellis tree” or simply a “trellis.” A sample trellis tree is shown in Figure 2-5.
IPUG32_02.7, June 2010
8
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Figure 2-5. Trellis Tree
00
01
0/00
1/00
0/00
1/00
0/01
1/01
0/01
1/01
0/01
1/01
0/10
1/10
0/10
1/10
0/11
1/11
0/11
1/11
0/10
10
11
1/10
0/11
1/11
0/00
1/00
Trellis for 3 stages and constraint length = 3
Branches corresponding to input seq. 101 is highlighted
In the above trellis, the branches for three transitions are drawn. The path of the trellis for a typical input sequence,
101, is highlighted in the figure. Any transmission error alters the path traversed in the trellis. In Viterbi decoding,
such a trellis is formed in memory, where the metrics corresponding to all paths are recorded. After constructing
the trellis for a sufficient length (called the traceback length, L), the traceback process starts from node 0 in the last
state. During the traceback process, the original sequence is reconstructed from the trellis. In error-prone applications, however, a trellis of length 2L is constructed and two traceback processes are employed. The first traceback
starts from node 0, traces back L stages of the trellis, and ends up in a node which is more likely to be the right
starting point for the second traceback. The second traceback starts from this reliable starting point and traces
back another L nodes. The data corresponding to the second traceback are decoded to result in the original data
stream.
Functional Description
A simplified implementation of the Lattice Block Viterbi Decoder IP is shown in Figure 2-6. A brief description of the
modules is given below.
Figure 2-6. Internal Architecture of the Viterbi Decoder
BER
din
BMU
ACS
MMU
TBU
BER
dout
MEM
Branch Metric Unit (BMU)
This module takes in the input data from the channel and computes a metric for each state and input combination.
The metric is the Hamming distance for hard-decision encoded data and l1 norm (sum of absolute values) for soft
decision encoded data. The BMU also includes a depuncturing unit for punctured codes. This module has three
major sub-modules: state encoder, metric computer, and de-puncture unit.
IPUG32_02.7, June 2010
9
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Add, Compare, and Select Unit (ACS)
The ACS unit adds the current metric to the accumulated metric for each path and also determines the least metric
for each state of the trellis. The accumulated metric is fetched from register files and stored back there, after adding
the current metric. ACS also writes the survivor trellis path (the previous state information) in memory.
Traceback Unit (TBU)
The TBU performs decoding of the received data by tracing back the trellis from an appropriate starting node.
Traceback and decoding is performed on a block of sequential nodes whose length is equal to the parameter Traceback Length. The Viterbi Decoder IP supports both one and two traceback schemes. In the one traceback scheme,
the traceback starts from node 0 and happens for length L, where L is the traceback length. In the two traceback
scheme, the first traceback starts from node 0 and happens for length L. This traceback determines a reliable starting node for the second traceback process. The second traceback starts from this reliable start node and happens
for another length L.
The number of tracebacks employed and the traceback length are mostly set by the user, but the choice is
restricted by other parameters and rules, as imposed by the Block Viterbi Decoder IP GUI.
Memory (MEM)
The memory stores the accumulated metric and the previous state information (traceback information).
Memory Management Unit (MMU)
The MMU generates addresses and read write signals for the memory during different phases of operation.
Bit Error Rate Monitor (BER)
This optional module is used to estimate the bit error rate of the channel. This is achieved by encoding the decoded
output symbols using the same generator polynomials and comparing them with delayed input to the Viterbi
decoder. Assuming the error in decoding is zero or negligible, the error determined by BER is equal to the channel
error.
Other Modules
In Zero Flushing block decoding, an additional module called “Zero Padding Unit” is used. When the block length is
not a multiple of the traceback length, the Zero Padding Unit automatically adds zero samples at the end of each
block of input data.
Configuring the Block Viterbi Decoder
Puncture Settings
The Viterbi Decoder can be configured as a punctured or non-punctured decoder. A punctured decoder actually
decodes convolutional codes that have been punctured after encoding. The puncture settings consist of the puncture block size (this is derived from code rate) and puncture patterns, PP0 and PP1. The puncture settings are
either fixed using the parameters in the IP GUI or can be dynamically set using input the ports, inrate, outrate,
pp0, pp1 and ppset. The values in inrate and outrate correspond to the rate factors k and n, respectively and
they result in a code rate of k/n. The numerator of the code rate representation, k or the inrate is also called as
the puncture block size in this document.
Continuous and Block Decoding
The decoding process can be applied on either continuous stream or blocks of input data. The main difference
between these modes lies in the way the decoder performs the traceback operation. When the decoder is configured in continuous mode, it always performs two length-L tracebacks. The actual traceback length is set by the user
through the IP GUI.
IPUG32_02.7, June 2010
10
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
On the other hand, if the decoder is configured in block mode, the number of tracebacks and traceback length
depends on the parameters of the decoder. The user has to specify the termination method that was used for the
convolutional coding to enable the decoder to start from the correct initial state.
In dynamic puncturing mode, only block decoding is permitted.
Termination Modes
Convolutional encoders employ two block terminations methods: 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.
Lattice’s Block Viterbi decoder IP supports both of these termination methods. The choice of termination method is
decided by the user and it must be exactly the same as what was used in the convolutional encoder.
Number of Tracebacks and Traceback Length
The accuracy of decoding depends to some extent on the starting node of a traceback operation. Usually, if the
data was encoded using the Zero Flushing scheme and if the traceback length is equal to block length, the traceback can start at state 0. For all other schemes or for a continuous decoder, starting the traceback from zero state
may not lead to right results. A reliable starting state can be determined by performing an additional traceback
operation. The Block Viterbi Decoder can be configured to perform either 1 or 2 tracebacks by setting the parameter Number of Tracebacks in the IP GUI. For some configurations, the number of tracebacks can be selected
by the user and for others, it is set automatically inside the decoder.
If Number of Tracebacks is equal to 1, the decoder performs length-L traceback starting from state 0 and does
decoding. If the Number of Tracebacks is equal to 2, the decoder performs a length-L traceback from state 0 to
determine a reliable starting point for second traceback. From that starting point, it performs a second length-L
traceback and does decoding. For continuous decoders and block decoders with Tail Biting termination mode,
Number of Tracebacks is internally set to 2. For block decoders with Zero Flushing termination mode, Number
of Tracebacks can be set to either 1 or 2 by the user.
The traceback length is typically close to 7 to 9 times the constraint length (K) in most applications. Lattice’s Viterbi
Decoder IP allows the user to specify any traceback length between 3K and 14K for most configurations; however,
the Traceback Length is restricted to be a multiple of puncture block size for fixed puncturing decoders. When
the Termination Mode is set to “Tail Biting”, the traceback length is internally set by the core to Block
Length*k/n. When the decoder operates in dynamic puncture mode and Number of Tracebacks is set to 1,
the Traceback Length should be a common multiple of all possible input rates and between 8. and 128. For
example, if Max Input Rate is 4, the possible input rates are 1, 2, 3 and 4. Therefore, the Traceback Length
can only be in the set {12, 24, 36, ..., 116, 128}.
Block Length
For block decoders, the block length is implicitly specified using the input signals ibstart and ibend. All the data
between ibstart and ibend pulses, including both the ends, are taken to be part of the block. When ibstart is
pulled high for one clock cycle the input data is read in as the first data of the block. The decoder continues to read
the data in consecutive clock cycles into a block until it encounters a one clock cycle pulse in the ibend port. The
block size has to be one of the legal values as given in Table 2-1, for the decoder to function correctly.
Table 2-1. Legal Values for Block Size
Termination Number of
Mode
Tracebacks
Puncturing
None
Zero Flushing
1
8 to 128
Zero Flushing
2
>8
Tail Biting
2
8 to 128
IPUG32_02.7, June 2010
Fixed
Dynamic
8 to 128*k/n, multiples of n
> 8, Traceback Length*outrate/inrate
> 8, multiples of n
> 8, multiples of outrate
8 to 128*k/n, multiples of n
Not Applicable
11
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Data Type
The Viterbi Decoder IP supports two commonly used binary representations, namely, sign-magnitude and
unsigned offset, for soft decision data. In sign-magnitude representation, the most significant bit is a sign bit and
the rest of the bits represent the magnitude. The most positive number corresponds to strong logic zero and other
positive numbers are weak logic zeros. The most negative number corresponds to strong logic one and other negative numbers are weak logic ones. In unsigned offset representation, there is no sign bit in the number and all
numbers are treated positive. The smallest number (all zeros) corresponds to strong logic zero and the biggest
number (all ones) corresponds to strong logic one. The smaller numbers counting up from zero are progressively
weaker logic zeros and bigger numbers counting down from the biggest number are progressively weaker logic
ones.
Table 2-2 shows the data values and their interpretation in “Signed” and “Unsigned” data type configurations when
Soft Width is 3.
Table 2-2. Interpretation of Signed and Unsigned Data
Signed Binary
Data
Unsigned Offset
Interpretation
111
-3
110
-2
101
-1
100
-0
000
0
001
1
010
2
011
3
Data
(strong logic 1)
(weaker logic 1s)
(weaker logic 0s)
(strong logic 0)
Interpretation
111
7
110
6
101
5
100
4
011
3
010
2
001
1
000
0
(strong logic 1)
(weaker logic 1s)
(weaker logic 0s)
(strong logic 0)
Signal Descriptions
The top level interface diagram of the Viterbi Decoder is shown in Figure 2-1. The details of the I/O ports are summarized in Table 2-3.
Table 2-3. Top Level I/O Interface
Port
Bits
I/O
clk
1
I
System clock
rstn
1
I
System wide asynchronous active-low reset signal
pbstart
1
I
“Punctured block start” signal to indicate the start of a new block of punctured
data. This signal is not available while decoding non-punctured codes.
ibstart
1
I
Input block start signal. This must be pulled high when the first data of a block is
applied on the input port. This port is available for block decoding only.
ibend
1
I
Input block end signal. This signal must be pulled high to indicate the last data
of a block being applied on the input port. This port is available for block decoding only.
1 or 3
to 8 (each)
I
Data input buses – The buses become one bit inputs for hard decision decoding
and equals to the soft width for soft decision decoding. The number of buses is 1
for punctured codes and n for non-punctured codes, where n is the code rate
factor, from 2 to 7.
inrate
1-4
I
Input rate of the convolutional code for next block. This port is available only in
dynamic puncturing mode.
outrate
2-5
I
Output rate of the convolutional code for next block. This port is available only in
dynamic puncturing mode.
din0, din1,
din2, din3,
din4, din5,
din6
IPUG32_02.7, June 2010
Description
12
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Table 2-3. Top Level I/O Interface (Continued)
Port
Bits
I/O
Description
pp0
1-12
I
Puncture pattern 0 of the convolutional code for next block. This port is available
only in dynamic puncturing mode.
pp1
1-12
I
Puncture pattern 1 of the convolutional code for next block. This port is available
only in dynamic puncturing mode.
ppset
1
I
Puncture rate and puncture pattern set signal. The new input rate, output rate
and puncture patterns are set when ppset goes high. This port is available only
in dynamic puncturing mode.
dout
1
O
Output decoded data.
outvalid
1
O
Output valid signal. This indicates the output on dout is a valid decoded value.
obvalid
1
O
Output block valid signal. This signal remains high for the entire duration of the
output block. This signal is present only for punctured and block decoding.
ber
16
O
Bit-error rate output. This port is available for continuous decoding only.
O
Identifies that a new Bit Error Rate (BER) value is available at the ber output
port. This signal goes high once every B clock cycles, where B=2^(BER
Period), is the duration over which BER is computed. This port is available for
continuous decoding only.
O
“Ready for input block” signal.
1. This port is not available for non-punctured decoders.
2. For fixed puncturing, this signal goes high every L*(2^c) cycles periodically
counting from ibstart for each input block, where L is the traceback length
and c is the hybrid index. After applying an input block (after ibend going
active), the user has to wait for the next rfib pulse before he can start giving the next input block. In fixed puncturing mode, this port is available only
for zero flushing block decoding and Number of Tracebacks is 2.
3. For dynamic puncturing, this port is always available. It goes low one cycle
after an input block starts (after ibstart signal going high). It goes high a
few cycles after an input block ends (after ibend going low).
bervalid
rfib
1
1
IPUG32_02.7, June 2010
13
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Interfacing with the Block Viterbi Decoder
Lattice’s Block Viterbi Decoder provides several handshake signals for interfacing the decoder with other sub-systems.
In non-punctured, continuous modes, the input and output data rates are the same and it is straightforward to connect the decoder in a system. The only control output in these modes, outvalid, indicates when the output data
is ready. Initially at reset, outvalid is low and it goes high after several clock cycles depending on the output
latency for the chosen configuration. The latency depends on different decoder parameters, but mainly on traceback length. A sample timing diagram for this configuration is shown in Figure 2-7. The hybrid version of the nonpunctured, continuous Viterbi decoder uses similar handshake mechanism as the parallel version. The main difference is that the data rate is a fraction of the clock rate for hybrid implementations. Figure 2-9 shows the timing diagram for a sample hybrid decoder.
A punctured, continuous mode Viterbi decoder has an additional input signal, pbstart, which is used to specify
the start of each punctured block. This signal is required to synchronize the punctured blocks correctly for depuncturing inside the decoder. As in non-punctured mode, the input is assumed to be continuous. The output will have
one gap per puncture block, which is indicated by outvalid going low. This gap is required to account for the data
rate differences between the input and the output of the decoder. Figure 2-8 shows the timing diagram for a sample
punctured, continuous decoder. The hybrid mode for this implementation has similar timing characteristics, except
that the data rate is a fraction of the clock rate and hence the data and output control signals accordingly span multiple clock cycles. However the input control signals are all single clock cycle pulses as they are scanned only for
one cycle. A sample timing diagram for a hybrid, punctured decoder is shown in Figure 2-10.
When a Viterbi Decoder is configured for block modes, the signals ibstart and ibend are used to specify the
start and end of input blocks. For fixed puncturing decoders, when the decoder is configured for zero flushing termination mode with two tracebacks, an additional output control signal rfib is provided. After an ibend signal is
applied signifying the end of a block, the next ibstart can only be applied, after the rfib goes high. To ensure
processing of blocks without discontinuity, the rfib signal goes high at the end of every L cycles, where L is the
traceback length. So if a block ends exactly at a traceback length boundary, rfib will go high while ibend goes
high, allowing ibstart to be applied in the next clock cycle. This way continuous blocks can be applied to the
decoder. For dynamic puncturing decoders, the rfib port is always present. The signal rfib goes low one cycle
after ibstart is received. It remains low during the time an input block is received. It goes high a few cycles after
ibend comes through. Refer to Figure 2-11 for a sample timing diagram for a block decoder.
When it is required to change the code rate or puncture pattern dynamically during the operation of the decoder,
the Block Viterbi Decoder can be configured as a dynamic puncturing decoder. In this mode, the code rate and
puncture patterns are set through input ports. The code rate is set using the input ports inrate and outrate.
Care should be taken to ensure the following rule is followed for the rates: inrate < outrate < 2*inrate. Otherwise the decoder will not function correctly. An exception to this rule is when inrate = 1, at which time, the outrate has to be 2. Each of the puncture patterns must be inrate bits wide and the total number of ‘1’s in PP0 and
PP1 must be equal to outrate. The values of inrate, outrate, PP0 and PP1 are read-in only when ppset
goes high. The new puncture settings are set when ppset goes high and they are effective from the next input
block. Before the decoder is applied with the first block, the puncture settings have to be set. Figure 2-12 shows the
timing diagram for a typical dynamic punctured decoder.
IPUG32_02.7, June 2010
14
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Timing Diagrams
The top-level timing diagrams for several cases are given in the Figure 2-7 through Figure 2-12.
Figure 2-7. Timing Diagram for a Continuous, Parallel, Non-Punctured Decoder
clk
din0
din1
...
x
2
1
3
4
5
6
7
8
9
10
11
x
x
1
2
3
4
5
6
output latency
outvalid
dout x
x
x
x
x
Figure 2-8. Timing Diagram for a Continuous, Parallel, Punctured (Rate=2/3) Decoder
clk
pbstart
x
din0
2
1
3
4
5
6
x
x
x
x
1
2
x
x
x
x
x
5
x
x
output latency
outvalid
dout
x
x
x
x
x
4
Figure 2-9. Timing Diagram for a Continuous, Hybrid (Two Cycles), Non-punctured Decoder
clk
din0
din1
...
x
1
2
3
4
5
6
x
1
2
3
output latency
outvalid
dout
x
x
x
Figure 2-10. Timing Diagram for a Continuous, Hybrid (Two cycles), Punctured (Rate=2/3) Decoder
clk
pbstart
din0
x
1
2
3
4
5
6
x
1
2
x
4
output latency
outvalid
dout
IPUG32_02.7, June 2010
x
x
15
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Figure 2-11. Timing Diagram for a Block, Parallel, Non-punctured Decoder with Two Tracebacks
clk
din0
din1
...
x
2
1
...
...
m
BL
x
x
1
2
3
x
1
2
...
m
ibstart
ibend
L
L
rfib
output latency
outvalid
dout
x
x
x
x
...
x
x
x
Figure 2-12. Timing Diagram for a Block, Parallel, Dynamic Punctured Decoder
clk
ppset
inrate
x
3
x
2
x
outrate
x
4
x
3
x
pp0
x
5
x
2
x
pp1
x
6
x
3
x
ibstart
pbstart
ibend
din
x
1
2
3
4
5
1
2
3
x
5
6
BL-1
BL
1
2
rfib
dout
1
2
x
4
outvalid
obvalid
IPUG32_02.7, June 2010
16
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Functional Description
Core Configurations
Table 2-4 lists the configurations and parameters for some standard configurations supported by the IP core.
Results for these configurations in each Lattice device family are provided in Appendix A: “Resource Utilization” on
page 31.
Table 2-4. Core Configurations
Configuration
Compatible Standard
1
2
3
4
5
IEEE 802.16IEEE 802.162004-OFDM PHY
2004-OFDM PHY
(dynamic
(fixed puncturing)
puncturing)
IEEE 802.16
2004- SC PHY
3GPP
DVB-S, IEEE
802.11A
3
9
7
7
7
2/3
1/2
1/2
1/2
5/6
Block
Block
Continuous
Block
Block
30
63
42
42
90
Tail Biting
Zero Flushing
Zero Flushing
Zero Flushing
2
2
-
2
2
Fixed
None
None
Dynamic
Fixed
Primary Options
Constraint length (K)
Code Rate (k/n)
Operation Mode
Traceback Length
Block Options
Termination Mode
Number of Tracebacks
Puncture Settings
Puncturing
Puncture Pattern
10
11
—
—
Through Port
10101
11010
Max Input Rate
—
—
—
5
—
Max Output Rate
—
—
—
6
—
Octal
Octal
Octal
Octal
Octal
78
58
5618
7538
1718
1338
1718
1338
1718
1338
Parallel
Parallel
Parallel
Parallel
Parallel
—
—
—
—
—
Soft Decision
Soft Decision
Soft Decision
Soft Decision
Soft Decision
3
3
3
3
4
Signed
Signed
Signed
Signed
Unsigned
BER Monitor
No
No
No
No
No
BER Period
—
—
—
—
—
Generator Polynomials
Radix
GP0, GP1 (GP2,...
N/A)
Implementation
Implementation Method
Hybrid Index
Inputs
Decoder Input
Soft Width
Data Type
BER (Bit Error Rate)
IPUG32_02.7, June 2010
17
Block Viterbi Decoder User’s Guide
Chapter 3:
Parameter Settings
The IPexpress™ tool is used to create IP and architectural modules in the Diamond or ispLEVER software. Refer to
“IP Core Generation” on page 22 for a description on how to generate the IP.
Table 3-1 provides the list of user configurable parameters for the Block Viterbi Decoder IP core. The parameter
settings are specified using the Block Viterbi Decoder IP core Configuration GUI in IPexpress. The numerous PCI
Express parameter options are partitioned across multiple GUI tabs as shown in this chapter.
Table 3-1. Block Viterbi Decoder Parameter Descriptions
Parameter
Range
Default
Primary Options
Constraint length (K)
3 to 9
3
Code Rate (k/n)
1/2, 1/3,...,1/7 for Non-Punctured Decoder
2/3, 3/4,..., 12/13 for Punctured Decoder
2/3
Operation Mode
Continuous/Block
Block
3K to 14K
30
Zero Flushing/Tail Biting
Tail Biting
1, 2
-
None/Fixed/Dynamic
Fixed
PP0 and PP1 are each k bits wide binary patterns
11
10
1 to 12 when Number of Tracebacks = 2
1 to 6 when Number of Tracebacks = 1
—
Traceback Length
Block Options
Termination Mode
Number of Tracebacks
Puncture Settings
Puncturing
Puncture Pattern
Max Input Rate
Max Output Rate
(Max Input Rate+1) to (2*Max Input Rate-1)
Generator Polynomials
Radix
GP0, GP1, GP2, GP3, GP4, GP5, GP6
Binary/Octal/Hexadecimal
Octal
K bits wide number for each polynomial
7
5
Parallel/Hybrid
Parallel
1 to (K-1)
—
Hard Decision/Soft Decision
Soft Decision
Implementation
Implementation Method
Hybrid Index
Inputs
Decoder Input
Soft Width
3 to 8 bits
3
Data Type
Signed/Unsigned
Signed
BER Monitor
Yes/No}
No
BER Period
4 to 32
—
BER (Bit Error Rate)
IPUG32_02.7, June 2010
18
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Parameter Settings
Primary Options Tab
Figure 3-1 shows the contents of the Primary Options tab.
Figure 3-1. Primary Options Tab
Primary Options
Constraint length (K)
Constraint length is equal to the number of input data values (present and past) used to generate the convolutional
code in the encoder.
Code Rate (k/n)
This is the symbol output rate of the encoder, defined as the number of output bits per input bit in the encoder. For
non-punctured decoder, this can be set from 1/2 to 1/7. For punctured decoder, this can be set to m/m+1, where m
can range from 2 to 12.
Operation Mode
The operation mode of the decoder is either continuous or block.
Block Options
Termination Mode
This is the termination mode used for the convolutional coding of the input block. This parameter is required for
block operation modes.
Number of Tracebacks
Number of tracebacks performed for decoding. This option is available only when zero-flushing termination mode is
used.
IPUG32_02.7, June 2010
19
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Parameter Settings
Traceback Length
Traceback length is the number of trellis states the decoder traces back for performing decoding. The traceback
length must be between 3K to 14K, where K is the Constraint Length. The range is further restricted by the value of
some block related parameters. See the Configuring the Block Viterbi Decoder section of this document for details.
Puncturing
This option specifies whether input data is punctured or not. If the input is punctured, the decoder can be set to use
either fixed puncture settings or dynamically variable puncture settings.
Puncture Settings
Puncture Pattern
Puncture pattern for fixed puncturing decoders. For dynamic puncture decoders, this pattern is applied through the
input port.
Max Input Rate
This is the maximum value for the numerator, k, of the code rate, when the puncture rate is dynamically set through
an input port.
Max Output Rate
This is the maximum value for the denominator, n, of the code rate, when the puncture rate is dynamically set
through an port.
Advanced Options Tab
Figure 3-2 shows the contents of the Advanced Options tab.
Figure 3-2. Advanced Options Tab
Generator Polynomials
Radix
This parameter specifies the number system in which the generator polynomials are specified.
IPUG32_02.7, June 2010
20
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Parameter Settings
GP0, GP1, GP2, GP3, GP4, GP5, GP6
Generator polynomials used for generating the convolutional code. Two polynomials are always used for punctured
decoders (either fixed or dynamic). For non-punctured decoders, the number of polynomials used is equal to n,
where n is denominator of the Code Rate (k/n).The width of each polynomial is equal to constraint length, K.
Implementation Method
The implementation method can be either “parallel” or “hybrid”. In the parallel implementation, the decoder can produce one output data in one cycle. In hybrid implementations, it takes multiple clock cycles to generate each output
data, but a smaller number of device resources are used.
Hybrid Index
This controls the resource-throughput trade-off in hybrid implementations. It takes 2Hybrid Index cycles to produce one
output data.
Inputs
Decoder Input
Specifies whether the decoder is fed with a hard decision or soft decision input. For punctured decoders, this option
is not available and decoder has to be fed with soft decision inputs.
Soft Width
Input data width for soft decision inputs.
Data Type
Specifies whether the input data type is represented in sign-magnitude form (signed) or unsigned offset form
(unsigned). See the section “configuring the Block Viterbi Decoder” for details.
BER (Bit Error Rate)
BER Monitor
Specifies whether the optional bit error rate (BER) monitor is added to the Viterbi decoder.
BER Period
This determines the duration for which the BER is accumulated. The BER value starts accumulating from zero for
up to 2^(BER Period) clock cycles. After this period, the accumulated value is placed on the BER output port. The
BER value is then reset and the monitor starts accumulating again.
IPUG32_02.7, June 2010
21
Block Viterbi Decoder User’s Guide
Chapter 4:
IP Core Generation
This chapter provides information on how to generate the Block Viterbi Decoder IP core using the Diamond or ispLEVER software IPexpress tool, and how to include the core in a top-level design.
Licensing the IP Core
An IP core- and device-specific license is required to enable full, unrestricted use of the Block Viterbi Decoder IP
corein a complete, top-level design. Instructions on how to obtain licenses for Lattice IP cores are given at:
http://www.latticesemi.com/products/intellectualproperty/aboutip/isplevercoreonlinepurchas.cfm
Users may download and generate the Block Viterbi Decoder IP core and fully evaluate the core through functional
simulation and implementation (synthesis, map, place and route) without an IP license. The Block Viterbi Decoder
IP corealso supports Lattice’s IP hardware evaluation capability, which makes it possible to create versions of the
IP core that operate in hardware for a limited time (approximately four hours) without requiring an IP license. See
“Hardware Evaluation” on page 27 for further details. However, a license is required to enable timing simulation, to
open the design in the Diamond or ispLEVER EPIC tool, and to generate bitstreams that do not include the hardware evaluation timeout limitation.
Getting Started
The Block Viterbi Decoder IP core is available for download from Lattice’s IP server using the IPexpress tool. The
IP files are automatically installed using ispUPDATE technology in any customer-specified directory. After the IP
core has been installed, the IP core will be available in the IPexpress GUI dialog box shown in Figure 4-1.
The IPexpress tool GUI dialog box for the Block Viterbi Decoder IP core is shown in Figure 4-1. To generate a specific IP core configuration the user specifies:
• Project Path – Path to the directory where the generated IP files will be loaded.
• File Name – “username” designation given to the generated IP core and corresponding folders and files.
• (Diamond) Module Output – Verilog or VHDL.
• (ispLEVER) Design Entry Type – Verilog HDL or VHDL.
• Device Family – Device family to which IP is to be targeted (e.g. LatticeSCM, Lattice ECP2M, LatticeECP3,
etc.). Only families that support the particular IP core are listed.
• Part Name – Specific targeted part within the selected device family.
IPUG32_02.7, June 2010
22
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
Figure 4-1. The IPexpress Tool Dialog Box (Diamond Version)
Note that if the IPexpress tool is called from within an existing project, Project Path, Module Output (Design Entry in
ispLEVER), Device Family and Part Name default to the specified project parameters. Refer to the IPexpress tool
online help for further information.
To create a custom configuration, the user clicks the Customize button in the IPexpress tool dialog box to display
the Block Viterbi Decoder IP coreConfiguration GUI, as shown in Figure 4-2. From this dialog box, the user can
select the IP parameter options specific to their application. Refer to “Parameter Settings” on page 18for more information on the Block Viterbi Decoder IP coreparameter settings.
IPUG32_02.7, June 2010
23
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
Figure 4-2. The IPexpress Tool Dialog Box - Configuration GUI (Diamond Version)
IPUG32_02.7, June 2010
24
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
IPexpress-Created Files and Top Level Directory Structure
When the user clicks the Generate button in the IP Configuration dialog box, the IP core and supporting files are
generated in the specified “Project Path” directory. The directory structure of the generated files is shown in
Figure 4-3.
Figure 4-3. LatticeECP3 Block Viterbi Decoder IP core Directory Structure
Table 4-1 provides a list of key files and directories created by the IPexpress tool and how they are used. The IPexpress tool creates several files that are used throughout the design cycle. The names of most of the created files
are customized to the user’s module name specified in the IPexpress tool.
Table 4-1. File List
File
Description
<username>_inst.v
This file provides an instance template for the IP.
<username>.v
This file provides the VITERBI core for simulation.
<username>_beh.v
This file provides a behavioral simulation model for the VITERBI core.
<username>_bb.v
This file provides the synthesis black box for the user’s synthesis.
<username>.ngo
*.ngo
The ngo files provide the synthesized IP core.
<username>.lpc
This file contains the IPexpress tool options used to recreate or modify the core in the
IPexpress tool.
<username>_generate.tcl
Created when GUI “Generate” button is pushed, invokes generation, may be run from
command line.
<username>_generate.log IPexpress scripts log file.
<username>_gen.log
IPUG32_02.7, June 2010
IPexpress IP generation log file
25
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
Instantiating the Core
The generated Viterbi IP core package includes black-box (<username>_bb.v) and instance (<user-name>_inst.v)
templates that can be used to instantiate the core in a top-level design. An example RTL top-level reference source
file that can be used as an instantiation template for the IP core is provided in 
\<project_dir>\blk_vd_eval\<username>\src\rtl\top. Users may also use this top-level reference as
the starting template for the top-level for their complete design.
Running Functional Simulation
Simulation support for the Viterbi IP core is provided for Aldec Active-HDL (Verilog and VHDL) simulator, Mentor
Graphics ModelSim simulator. The functional simulation includes a configuration-specific behavioral model of the
Viterbi IP core. The test bench sources stimulus to the core, and monitors output from the core. The generated IP
core package includes the configuration-specific behavior model (<username>_beh.v) for functional simulation in
the “Project Path” root directory. The simulation scripts supporting ModelSim evaluation simulation is provided in
\<project_dir>\blk_vd_eval\<username>\sim\modelsim\scripts. The simulation script supporting
Aldec evaluation simulation is provided in 
\<project_dir>\blk_vd_eval\<username>\sim\aldec\scripts. Both ModelSim and Aldec simulation
is supported via test bench files provided in \<project_dir>\blk_vd_eval\testbench. Models required for
simulation are provided in the corresponding \models folder. Users may run the Aldec evaluation simulation by
doing the following:
1. Open Active-HDL.
2. Under the Tools tab, select Execute Macro.
3. Browse to folder \<project_dir>\blk_vd_eval\<username>\sim\aldec\scripts and execute one
of the "do" scripts shown.
Users may run the ModelSim evaluation simulation by doing the following:
1. Open ModelSim.
2. Under the File tab, select Change Directory and choose the folder 
<project_dir>\blk_vd_eval\<username>\sim\modelsim\scripts.
3. Under the Tools tab, select Execute Macro and execute the ModelSim “do” script shown.
Note: When the simulation completes, a pop-up window will appear asking “Are you sure you want to finish?”
Answer No to analyze the results. Answering Yes closes ModelSim.
Synthesizing and Implementing the Core in a Top-Level Design
The Block Viterbi Decoder IP itself is synthesized and provided in NGO format when the core is generated through
IPexpress. You may combine the core in your own top-level design by instantiating the core in your top-level file as
described in “Instantiating the Core” on page 26 and then synthesizing the entire design with either Synplify or Precision RTL Synthesis.
The following text describes the evaluation implementation flow for Windows platforms. The flow for Linux and
UNIX platforms is described in the Readme file included with the IP core.
The top-level file <userame>_top.v is provided in 
\<project_dir>\blk_vd_eval\<username>\src\rtl\top. Push-button implementation of the reference
design is supported via the project file <username>.ldf (Diamond) or .syn (ispLEVER) located in
\<project_dir>\blk_vd_eval\<username>\impl\(synplify or precision).
IPUG32_02.7, June 2010
26
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
To use this project file in Diamond:
1. Choose File > Open > Project.
2. Browse to 
\<project_dir>\blk_vd_eval\<username>\impl\synplify (or precision) in the Open Project
dialog box.
3. Select and open <username>.ldf. At this point, all of the files needed to support top-level synthesis and implementation will be imported to the project.
4. Select the Process tab in the left-hand GUI window.
5. Implement the complete design via the standard Diamond GUI flow.
To use this project file in ispLEVER:
1. Choose File > Open Project.
2. Browse to 
\<project_dir>\blk_vd_eval\<username>\impl\synplify (or precision) in the Open Project
dialog box.
3. Select and open <username>.syn. At this point, all of the files needed to support top-level synthesis and implementation will be imported to the project.
4. Select the device top-level entry in the left-hand GUI window.
5. Implement the complete design via the standard ispLEVER GUI flow.
Hardware Evaluation
The Block Viterbi Decoder IP supports Lattice’s IP hardware evaluation capability, which makes it possible to create
versions of the IP core that operate in hardware for a limited period of time (approximately four hours) without
requiring the purchase of an IP license. It may also be used to evaluate the core in hardware in user-defined
designs.
Enabling Hardware Evaluation in Diamond:
Choose Project > Active Strategy > Translate Design Settings. The hardware evaluation capability may be
enabled/disabled in the Strategy dialog box. It is enabled by default.
Enabling Hardware Evaluation in ispLEVER:
In the Processes for Current Source pane, right-click the Build Database process and choose Properties from the
dropdown menu. The hardware evaluation capability may be enabled/disabled in the Properties dialog box. It is
enabled by default.
Updating/Regenerating the IP Core
By regenerating an IP core with the IPexpress tool, you can modify any of its settings including: device type, design
entry method, and any of the options specific to the IP core. Regenerating can be done to modify an existing IP
core or to create a new but similar one.
Regenerating an IP Core in Diamond
To regenerate an IP core in Diamond:
1. In IPexpress, click the Regenerate button.
2. In the Regenerate view of IPexpress, choose the IPX source file of the module or IP you wish to regenerate.
IPUG32_02.7, June 2010
27
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
IP Core Generation
3. IPexpress shows the current settings for the module or IP in the Source box. Make your new settings in the Target box.
4. If you want to generate a new set of files in a new location, set the new location in the IPX Target File box. The
base of the file name will be the base of all the new file names. The IPX Target File must end with an .ipx extension.
5. Click Regenerate. The module’s dialog box opens showing the current option settings.
6. In the dialog box, choose the desired options. To get information about the options, click Help. Also, check the
About tab in IPexpress for links to technical notes and user guides. IP may come with additional information. As
the options change, the schematic diagram of the module changes to show the I/O and the device resources
the module will need.
7. To import the module into your project, if it’s not already there, select Import IPX to Diamond Project (not
available in stand-alone mode).
8. Click Generate.
9. Check the Generate Log tab to check for warnings and error messages.
10.Click Close.
The IPexpress package file (.ipx) supported by Diamond holds references to all of the elements of the generated IP
core required to support simulation, synthesis and implementation. The IP core may be included in a user's design
by importing the .ipx file to the associated Diamond project. To change the option settings of a module or IP that is
already in a design project, double-click the module’s .ipx file in the File List view. This opens IPexpress and the
module’s dialog box showing the current option settings. Then go to step 6 above.
Regenerating an IP Core in ispLEVER
To regenerate an IP core in ispLEVER:
1. In the IPexpress tool, choose Tools > Regenerate IP/Module.
2. In the Select a Parameter File dialog box, choose the Lattice Parameter Configuration (.lpc) file of the IP core
you wish to regenerate, and click Open.
3. The Select Target Core Version, Design Entry, and Device dialog box shows the current settings for the IP core
in the Source Value box. Make your new settings in the Target Value box.
4. If you want to generate a new set of files in a new location, set the location in the LPC Target File box. The base
of the .lpc file name will be the base of all the new file names. The LPC Target File must end with an .lpc extension.
5. Click Next. The IP core’s dialog box opens showing the current option settings.
6. In the dialog box, choose desired options. To get information about the options, click Help. Also, check the
About tab in the IPexpress tool for links to technical notes and user guides. The IP core might come with additional information. As the options change, the schematic diagram of the IP core changes to show the I/O and
the device resources the IP core will need.
7. Click Generate.
8. Click the Generate Log tab to check for warnings and error messages.
IPUG32_02.7, June 2010
28
Block Viterbi Decoder User’s Guide
Chapter 5:
Support Resources
This chapter contains information about Lattice Technical Support, additional references, and document revision
history.
Lattice Technical Support
There are a number of ways to receive technical support.
Online Forums
The first place to look is Lattice Forums (http://www.latticesemi.com/support/forums.cfm). Lattice Forums contain a
wealth of knowledge and are actively monitored by Lattice Applications Engineers.
Telephone Support Hotline
Receive direct technical support for all Lattice products by calling Lattice Applications from 5:30 a.m. to 6 p.m.
Pacific Time.
• For USA & Canada: 1-800-LATTICE (528-8423)
• For other locations: +1 503 268 8001
In Asia, call Lattice Applications from 8:30 a.m. to 5:30 p.m. Beijing Time (CST), +0800 UTC. Chinese and English
language only.
• For Asia: +86 21 52989090
E-mail Support
• [email protected]
• [email protected]
Local Support
Contact your nearest Lattice Sales Office.
Internet
www.latticesemi.com
References
[1] 3GPP TS 25.212 V4.2.0 (2001-09)
[2] 3GPP2 C.S0002-A Version 5.0 Date: July 13, 2001
[3] IEEE Standard for Local and Metropolitan Area Networks, Part 16: Air Interface for Fixed Broadband Wireless
Access Systems, October 2004 (IEEE Standard 802.16-2004)
[4] IEEE Standard for Information Technology Part 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications
[5] Digital Video Broadcasting (DVB): Framing Structure, Channel Coding and Modulation for 11/12 GHz Satellite
Services, ETSI- EN 300 421, 1997-98.
LatticeEC/ECP
• HB1000, LatticeEC/ECP Family Handbook
IPUG32_02.7, June 2010
29
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Support Resources
LatticeECP2M
• HB1003, LatticeECP2M Family Handbook
LatticeECP3
• HB1009, LatticeECP3 Family Handbook
LatticeSC/M
• DS1004, LatticeSC/M Family Data Sheet
LatticeXP
• HB1001, LatticeXP Family Handbook
LatticeXP2
• DS1009, Lattice XP2 Datasheet
Revision History
Date
Document
Version
IP
Versions
—
—
4.0
Previous Lattice releases.
02.3
4.1
Updated appendices. Added support for LatticeECP2M device
family.
May 2007
02.4
4.2
Updated appendices. Added support for LatticeXP2 device family.
April 2008
02.5
4.3
Updated appendices.
02.6
4.4
Updated appendices and added support for the LatticeECP3
device family.
02.7
4.5
Added support for Diamond software.
December 2006
May 2009
June 2010
Change Summary
Divided document into chapters. Added table of contents.
Added Quick Facts table in Chapter 1, “Introduction.”
Added new content in Chapter 4, “IP Core Generation.”
IPUG32_02.7, June 2010
30
Block Viterbi Decoder User’s Guide
Appendix A:
Resource Utilization
This appendix gives resource utilization information for Lattice FPGAs using the Block Viterbi Decoder IP core.
IPexpress is the Lattice IP configuration utility, and is included as a standard feature of the Diamond and ispLEVER
design tools. Details regarding the usage of IPexpress can be found in the IPexpress and Diamond and ispLEVER
help systems. For more information on the Diamond or ispLEVER design tools, visit the Lattice web site at:
www.latticesemi.com/software.
LatticeECP and LatticeEC FPGAs
Table A-1. Performance and Resource Utilization1
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM™
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
280
457
232
11
2
126
3GPP
See Table 2-4 on
page 17.
5041
9922
3160
13
16
101
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1310
2562
864
10
4
106
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(dynamic puncturing)
page 17.
1474
2742
1032
29
4
108
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(fixed puncturing)
page 17.
1735
3254
1185
13
4
108
Configuration
1. Performance and utilization data are generated targeting an LFEC20E-5F672C device using Lattice Diamond 1.0 and Synplify Pro
D-2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or
speed grade within the LatticeECP/EC family.
Ordering Part Number
The Ordering Part Number (OPN) for the Block Viterbi Decoder IP on the LatticeEC devices is VTERB-BLK-E2-U4.
LatticeECP2 FPGAs
Table A-2. Performance and Resource Utilization1
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
291
469
232
11
2
207
3GPP
See Table 2-4 on
page 17.
6345
11747
3160
13
16
138
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1636
3017
864
10
4
178
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(dynamic puncturing)
page 17.
1801
3201
1032
29
4
175
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(fixed puncturing)
page 17.
1935
3467
1185
13
4
129
Configuration
1. Performance and utilization data are generated targeting an LFE2-50E-7F484C device using Lattice Diamond 1.0 and Synplify Pro D2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the LatticeECP2 family.
IPUG32_02.7, June 2010
31
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Resource Utilization
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP2 devices is VTERB-BLKP2- U4.
LatticeECP2M FPGAs
Table A-3. Performance and Resource Utilization1
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
291
469
232
11
2
211
3GPP
See Table 2-4 on
page 17.
6345
11747
3160
13
16
135
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1636
3017
864
10
4
179
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(dynamic puncturing)
page 17.
1801
3201
1032
29
4
176
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(fixed puncturing)
page 17.
1935
3467
1185
13
4
176
Configuration
1. Performance and utilization data are generated targeting an LFE2M-35E-7F672C device using Lattice Diamond 1.0 and Synplify Pro D2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the LatticeECP2M family.
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP2M devices is VTERB-BLKPM-U4.
LatticeECP3 FPGAs
Table A-4. Performance and Resource Utilization1
Configuration
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4
on page 17.
285
469
232
11
2
187
3GPP
See Table 2-4
on page 17.
6349
11736
3159
13
16
132
DVB-S, IEEE 802.11a
See Table 2-4
on page 17.
1626
3011
864
10
4
168
IEEE 802.16 2004-OFDM PHY See Table 2-4
(dynamic puncturing)
on page 17.
1768
3191
1032
29
4
171
IEEE 802.16 2004-OFDM PHY See Table 2-4
(fixed puncturing)
on page 17.
1935
3485
1185
13
4
146
1. Performance and utilization data are generated targeting an LFE3-95E-8FN672CES device using Lattice Diamond 1.0 and Synplify Pro D-2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or speed grade within the LatticeECP3 family
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP3 devices is VTERB-BLKE3-U4.
IPUG32_02.7, June 2010
32
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Resource Utilization
LatticeSC and LatticeSCM FPGAs
Table A-5. Performance and Resource Utilization1
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
263
433
233
11
2
261
3GPP
See Table 2-4 on
page 17.
4923
9426
3391
13
16
207
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1239
2438
864
10
4
236
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(dynamic puncturing)
page 17.
1389
2617
1032
29
4
230
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(fixed puncturing)
page 17.
1743
3227
1186
13
4
224
Configuration
1. Performance and utilization data are generated targeting an LFSCM3GA25E-7F900C device using Lattice Diamond 1.0 and Synplify
Pro D-2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or
speed grade within the LatticeSC/SCM family.
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeSC/M devices is VTERB-BLKSC-U4.
LatticeXP FPGAs
Table A-6. Performance and Resource Utilization1
Configuration
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
280
457
232
11
2
116
3GPP
See Table 2-4 on
page 17.
5041
9922
3160
13
16
92
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1310
2562
864
10
4
101
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(dynamic puncturing)
page 17.
1474
2742
1032
29
4
104
IEEE 802.16 2004-OFDM PHY See Table 2-4 on
(fixed puncturing)
page 17.
1735
3254
1185
13
4
100
1. Performance and utilization data are generated targeting an LFXP20E-5F256C device using Lattice Diamond 1.0 and Synplify Pro D2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the LatticeXP family.
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeXP devices is VTERB-BLK-XMU4.
IPUG32_02.7, June 2010
33
Block Viterbi Decoder User’s Guide
Lattice Semiconductor
Resource Utilization
LatticeXP2 FPGAs
Table A-7. Performance and Resource Utilization1
Configuration
Parameters
SLICEs
LUTs
Registers
IOB
sysMEM
EBRs
fMAX
(MHz)
IEEE 802.16a 2004-SC-PHY
See Table 2-4 on
page 17.
291
469
232
11
2
183
3GPP
See Table 2-4 on
page 17.
6345
1147
3160
13
16
128
DVB-S, IEEE 802.11a
See Table 2-4 on
page 17.
1636
3017
864
10
4
160
IEEE 802.16 2004-OFDM
PHY (dynamic puncturing)
See Table 2-4 on
page 17.
1801
3201
1032
29
4
153
IEEE 802.16 2004-OFDM
PHY (fixed puncturing)
See Table 2-4 on
page 17.
1935
3467
1185
13
4
136
1. Performance and utilization data are generated targeting an LFXP2-17E-7F484C device using Lattice Diamond 1.0 and Synplify Pro
D-2009.12L-1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the LatticeXP2 family.
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeXP2 devices is VTERB-BLK-X2U4.
IPUG32_02.7, June 2010
34
Block Viterbi Decoder User’s Guide