June 2010
IPUG32_02.7
Block Viterbi Decoder User’s Guide
© 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
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
Table of Contents
Lattice Semiconductor Table of Contents
IPUG32_02.7, June 2010 3 Block Viterbi Decoder User’s Guide
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 4 Block Viterbi Decoder User’s Guide
The Block Viterbi Decoder IP core is a parameterizable Viterbi Decoder for decoding different combinations of con-
volutionally encoded sequences. The decoder supports various code rates, constraint lengths, and generator poly-
nomials. 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 appli-
cation. The code rate and puncture pattern can also be changed dynamically through input ports during the opera-
tion 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™, Lat-
ticeECP™, 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
DVB-S
IEEE
802.11A
IEEE 802.16-
2004-OFDM
PHY
(dynamic
puncturing)
IEEE 802.16-
2004-OFDM
PHY (fixed
puncturing)
Core
Requirements
FPGA Families Supported LatticeEC/ECP/XP
Minimal Device Needed
LFEC1E
LFECP6E
LFXP3C
LFEC10E
LFECP10E
LFXP10C
LFEC3E
LFECP6E
LFXP3C
LFEC3E
LFECP6E
LFXP3C
LFEC6E
LFECP6E
LFXP6C
Resource
Utilization
Targeted Device LFEC20E-5F672C/ LFECP20E-5F672C/ LFXP20E-5F256C
LUTs 500 9950 2600 2750 3300
sysMEM EBRs 2 16 4 4 4
Registers 250 3200 900 1050 1200
Design Tool
Support
Lattice Implementation Diamond® 1.0 or ispLEVER® 8.1
Synthesis Synopsys® Synplify® Pro for Lattice D-2009.12L-1
Simulation Aldec® Active-HDL® 8.2 Lattice Edition
Mentor Graphics® ModelSim® SE 6.3F
Chapter 1:
Introduction
Core
Requirements
FPGA Families Supported LatticeECP2/ECP2M/XP2
Minimal Device Needed
LFE2-6E
LFE2M20E
LFXP2-5E
LFE2-12E
LFE2M20E
LFXP2-17E
LFE2-6E
LFE2M20
E
LFXP2-5E
LFE2-6E
LFE2M20E
LFXP2-5E
LFE2-6E
LFE2M20E
LFXP2-5E
Resource
Utilization
Targeted Device LFE2-50E-7F484C/ LFE2M35E-7F672C/ LFXP2-30E-7F484C
LUTs 500 11800 3050 3250 3500
sysMEM EBRs 216 4 4 4
Registers 250 3200 900 1050 1200
Design Tool
Support
Lattice Implementation Diamond 1.0 or ispLEVER 8.1
Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1
Simulation Aldec Active-HDL 8.2 Lattice Edition
Mentor Graphics ModelSim SE 6.3F
Lattice Semiconductor Introduction
IPUG32_02.7, June 2010 5 Block Viterbi Decoder User’s Guide
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
DVB-S
IEEE
802.11A
IEEE 802.16-
2004-OFDM
PHY
(dynamic
puncturing)
IEEE 802.16-
2004-OFDM
PHY (fixed
puncturing)
Table 1-3. Block Viterbi Decoder IP Core for LatticeSC/SCM Devices Quick Facts
Block Viterbi IP Configuration
IEEE
802.16
2004- SC
PHY 3GPP
DVB-S
IEEE
802.11A
IEEE 802.16-
2004-OFDM
PHY
(dynamic
puncturing)
IEEE
802.16-
2004-OFDM
PHY (fixed
puncturing)
Core
Requirements
FPGA Families Supported LatticeSC/SCM
Minimal Device Needed LFSC3GA15E/LFSCM3GA15EP1
Resource
Utilization
Targeted Device LFSC3GA25E-7F900C/ LFSCM3GA25EP1-7F900C
LUTs 450 9450 2450 2650 3250
sysMEM EBRs 2 16 4 4 4
Registers 250 3400 900 1050 1200
Design Tool
Support
Lattice Implementation Diamond 1.0 or ispLEVER 8.1
Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1
Simulation Aldec Active-HDL 8.2 Lattice Edition
Mentor Graphics ModelSim SE 6.3F
Core
Requirements
FPGA Families Supported LatticeECP3
Minimal Device Needed LFE3-35EA
Resource
Utilization
Targeted Device LFE3-95E-8FN672CES
LUTs 500 11750 3050 3200 3500
sysMEM EBRs 216 4 4 4
Registers 250 3200 900 1050 1200
Design Tool
Support
Lattice Implementation Diamond 1.0 or ispLEVER 8.1
Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1
Simulation Aldec Active-HDL 8.2 Lattice Edition
Mentor Graphics ModelSim SE 6.3F
Lattice Semiconductor Introduction
IPUG32_02.7, June 2010 6 Block Viterbi Decoder User’s Guide
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 deci-
sion for punctured codes
• Fully parallel or hybrid implementations. For a hybrid implementation, the degree of parallelism is parameteriz-
able
• 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
Table 1-4. Block Viterbi Decoder IP Core for LatticeECP3 Devices Quick Facts
Block Viterbi IP Configuration
IEEE
802.16
2004- SC
PHY 3GPP
DVB-S
IEEE
802.11A
IEEE 802.16-
2004-OFDM
PHY
(dynamic
puncturing)
IEEE
802.16-
2004-OFDM
PHY (fixed
puncturing)
IPUG32_02.7, June 2010 7 Block Viterbi Decoder User’s Guide
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
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 dig-
ital data stream.
Figure 2-2. Digital Transmit-Receive System
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).
din0
din1
din2
dout
clk
rstn
outvalid
ber
pbstart
obvalid
bervalid
Block
Viterbi Decoder
din3
din4
din5
din6
ibstart
ibend
rfib
ppset
inrate
outrate
pp0
pp1
Convolutional
Encoder
Transmitted
Data Stream
Received
Data Stream
Block Viterbi
Decoder
Modulator DemodulatorChannel
Noise
Chapter 2:
Functional Description
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 8 Block Viterbi Decoder User’s Guide
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
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
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’. 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 punc-
tured.
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.
reg
data out
data in
GP0 = 171 octal
GP1 = 133 octal
XOR
reg reg reg reg reg
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
01
10
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
5
Input data
After convolutional coding
Puncture pattern
superimposed
Puncture pattern
Final punctured output
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 9 Block Viterbi Decoder User’s Guide
Figure 2-5. Trellis Tree
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 applica-
tions, 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
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.
00
01
10
11
0/01 0/01 0/01
0/10 0/10 0/10
0/11 0/11 0/11
1/00 1/00 1/00
1/01 1/01 1/01
1/10 1/10 1/10
1/11 1/11 1/11
0/000/00 0/00
Trellis for 3 stages and constraint length = 3
Branches corresponding to input seq. 101 is highlighted
BMU
MMU MEM
ACS TBU
BER
din dout
BER
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 10 Block Viterbi Decoder User’s Guide
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 Trace-
back 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 start-
ing 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 punc-
ture 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 config-
ured in continuous mode, it always performs two length-L tracebacks. The actual traceback length is set by the user
through the IP GUI.
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 11 Block Viterbi Decoder User’s Guide
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 trace-
back 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 parame-
ter 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
Mode
Number of
Tracebacks
Puncturing
None Fixed Dynamic
Zero Flushing 1 8 to 128 8 to 128*k/n, multiples of n> 8, Traceback Length*outrate/inrate
Zero Flushing 2 > 8 > 8, multiples of n> 8, multiples of outrate
Tail Biting 2 8 to 128 8 to 128*k/n, multiples of nNot Applicable
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 12 Block Viterbi Decoder User’s Guide
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 neg-
ative 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
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 sum-
marized in Table 2-3.
Signed Binary Unsigned Offset
Data Interpretation Data Interpretation
111 -3 (strong logic 1) 111 7 (strong logic 1)
110 -2
(weaker logic 1s)
110 6
(weaker logic 1s)
101 -1 101 5
100 -0 100 4
000 0
(weaker logic 0s)
011 3
(weaker logic 0s)
001 1010 2
010 2001 1
011 3 (strong logic 0) 000 0 (strong logic 0)
Table 2-3. Top Level I/O Interface
Port Bits I/O Description
clk 1 I System clock
rstn 1 I System wide asynchronous active-low reset signal
pbstart 1I
“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 1I
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 1I
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 decod-
ing only.
din0, din1,
din2, din3,
din4, din5,
din6
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.
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 13 Block Viterbi Decoder User’s Guide
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 1I
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 1O
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.
bervalid 1O
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.
rfib 1O
“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 giv-
ing 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).
Table 2-3. Top Level I/O Interface (Continued)
Port Bits I/O Description
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 14 Block Viterbi Decoder User’s Guide
Interfacing with the Block Viterbi Decoder
Lattice’s Block Viterbi Decoder provides several handshake signals for interfacing the decoder with other sub-sys-
tems.
In non-punctured, continuous modes, the input and output data rates are the same and it is straightforward to con-
nect 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 trace-
back length. A sample timing diagram for this configuration is shown in Figure 2-7. The hybrid version of the non-
punctured, continuous Viterbi decoder uses similar handshake mechanism as the parallel version. The main differ-
ence is that the data rate is a fraction of the clock rate for hybrid implementations. Figure 2-9 shows the timing dia-
gram 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 depunc-
turing 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 mul-
tiple 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 termi-
nation 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. Other-
wise the decoder will not function correctly. An exception to this rule is when inrate = 1, at which time, the out-
rate 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.
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 15 Block Viterbi Decoder User’s Guide
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
Figure 2-8. Timing Diagram for a Continuous, Parallel, Punctured (Rate=2/3) Decoder
Figure 2-9. Timing Diagram for a Continuous, Hybrid (Two Cycles), Non-punctured Decoder
Figure 2-10. Timing Diagram for a Continuous, Hybrid (Two cycles), Punctured (Rate=2/3) Decoder
clk
din0
din1
...
dout
x13
4
xxxx12
outvalid
xxx
2
output latency
5678910
34 5
6
11
clk
dout
x134
xxxx12
xxx
2
x45x
xx
56x
xx
output latency
pbstart
outvalid
x
x
din0
clk
dout
x12
xx12
outvalid
xx3
53 6
4
output latency
din0
din1
...
clk
dout
x16
4
xx12
x
2
4x
53
output latency
pbstart
outvalid
din0
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 16 Block Viterbi Decoder User’s Guide
Figure 2-11. Timing Diagram for a Block, Parallel, Non-punctured Decoder with Two Tracebacks
Figure 2-12. Timing Diagram for a Block, Parallel, Dynamic Punctured Decoder
clk
dout
x1... m
xxx12
outvalid
xx
2
... m
12
... BL 3
xx
output latency
ibstart
ibend
rfib
din0
din1
...
LL
x
... x
x
clk
dout
ppset
outvalid
23
ibstart
rfib
obvalid
pbstart
x
x4x
x5x
x6x
1
inrate
outrate
pp0
pp1
1234 5
x
din
2
x3
3
2
3
BL 1
x5x
124
ibend
BL-1 2
x
x
x
x
6
Lattice Semiconductor Functional Description
IPUG32_02.7, June 2010 17 Block Viterbi Decoder User’s Guide
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 1 2 3 4 5
Compatible Standard IEEE 802.16
2004- SC PHY 3GPP DVB-S, IEEE
802.11A
IEEE 802.16-
2004-OFDM PHY
(dynamic
puncturing)
IEEE 802.16-
2004-OFDM PHY
(fixed puncturing)
Primary Options
Constraint length (K) 39777
Code Rate (k/n) 2/3 1/2 1/2 1/2 5/6
Operation Mode Block Block Continuous Block Block
Traceback Length 30 63 42 42 90
Block Options
Termination Mode Tail Biting Zero Flushing Zero Flushing Zero Flushing
Number of Tracebacks 22- 22
Puncture Settings
Puncturing Fixed None None Dynamic Fixed
Puncture Pattern 10
11 — — Through Port 10101
11010
Max Input Rate ——— 5 —
Max Output Rate ——— 6 —
Generator Polynomials
Radix Octal Octal Octal Octal Octal
GP0, GP1 (GP2,...
N/A)
78
58
5618
7538
1718
1338
1718
1338
1718
1338
Implementation
Implementation Method Parallel Parallel Parallel Parallel Parallel
Hybrid Index —————
Inputs
Decoder Input Soft Decision Soft Decision Soft Decision Soft Decision Soft Decision
Soft Width 33334
Data Type Signed Signed Signed Signed Unsigned
BER (Bit Error Rate)
BER Monitor No No No No No
BER Period —————
IPUG32_02.7, June 2010 18 Block Viterbi Decoder User’s Guide
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
Traceback Length 3K to 14K30
Block Options
Termination Mode Zero Flushing/Tail Biting Tail Biting
Number of Tracebacks 1, 2 -
Puncture Settings
Puncturing None/Fixed/Dynamic Fixed
Puncture Pattern PP0 and PP1 are each k bits wide binary patterns 11
10
Max Input Rate 1 to 12 when Number of Tracebacks = 2
1 to 6 when Number of Tracebacks = 1 —
Max Output Rate (Max Input Rate+1) to (2*Max Input Rate-1)
Generator Polynomials
Radix Binary/Octal/Hexadecimal Octal
GP0, GP1, GP2, GP3, GP4, GP5, GP6 K bits wide number for each polynomial 7
5
Implementation
Implementation Method Parallel/Hybrid Parallel
Hybrid Index 1 to (K-1) —
Inputs
Decoder Input Hard Decision/Soft Decision Soft Decision
Soft Width 3 to 8 bits 3
Data Type Signed/Unsigned Signed
BER (Bit Error Rate)
BER Monitor Yes/No} No
BER Period 4 to 32 —
Chapter 3:
Parameter Settings
Lattice Semiconductor Parameter Settings
IPUG32_02.7, June 2010 19 Block Viterbi Decoder User’s Guide
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.
Lattice Semiconductor Parameter Settings
IPUG32_02.7, June 2010 20 Block Viterbi Decoder User’s Guide
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.
Lattice Semiconductor Parameter Settings
IPUG32_02.7, June 2010 21 Block Viterbi Decoder User’s Guide
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 pro-
duce 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 22 Block Viterbi Decoder User’s Guide
This chapter provides information on how to generate the Block Viterbi Decoder IP core using the Diamond or isp-
LEVER 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 hard-
ware 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 spe-
cific 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.
Chapter 4:
IP Core Generation
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 23 Block Viterbi Decoder User’s Guide
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 infor-
mation on the Block Viterbi Decoder IP coreparameter settings.
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 24 Block Viterbi Decoder User’s Guide
Figure 4-2. The IPexpress Tool Dialog Box - Configuration GUI (Diamond Version)
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 25 Block Viterbi Decoder User’s Guide
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 IPex-
press 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 IPexpress IP generation log file
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 26 Block Viterbi Decoder User’s Guide
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 Pre-
cision 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).
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 27 Block Viterbi Decoder User’s Guide
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 imple-
mentation 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 imple-
mentation 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.
Lattice Semiconductor IP Core Generation
IPUG32_02.7, June 2010 28 Block Viterbi Decoder User’s Guide
3. IPexpress shows the current settings for the module or IP in the Source box. Make your new settings in the Tar-
get 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 exten-
sion.
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 exten-
sion.
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 addi-
tional 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 29 Block Viterbi Decoder User’s Guide
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
• techsupport@latticesemi.com
• techsupport-asia@latticesemi.com
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
Chapter 5:
Support Resources
Lattice Semiconductor Support Resources
IPUG32_02.7, June 2010 30 Block Viterbi Decoder User’s Guide
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
—Previous Lattice releases.
December 2006 Updated appendices. Added support for LatticeECP2M device
family.
May 2007 Updated appendices. Added support for LatticeXP2 device family.
April 2008 Updated appendices.
May 2009 Updated appendices and added support for the LatticeECP3
device family.
Added support for Diamond software.
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.”
Date
Document
Version
IP
Versions Change Summary
—4.0
02.3 4.1
02.4 4.2
02.5 4.3
02.6 4.4
June 2010 02.7 4.5
IPUG32_02.7, June 2010 31 Block Viterbi Decoder User’s Guide
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
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
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 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
(dynamic puncturing)
See Table 2-4 on
page 17. 1474 2742 1032 29 4 108
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4 on
page 17. 1735 3254 1185 13 4 108
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.
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 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
(dynamic puncturing)
See Table 2-4 on
page 17. 1801 3201 1032 29 4 175
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4 on
page 17. 1935 3467 1185 13 4 129
1. Performance and utilization data are generated targeting an LFE2-50E-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 LatticeECP2 family.
Appendix A:
Resource Utilization
Lattice Semiconductor Resource Utilization
IPUG32_02.7, June 2010 32 Block Viterbi Decoder User’s Guide
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP2 devices is VTERB-BLK-
P2- U4.
LatticeECP2M FPGAs
Table A-3. Performance and Resource Utilization1
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP2M devices is VTERB-BLK-
PM-U4.
LatticeECP3 FPGAs
Table A-4. Performance and Resource Utilization1
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP3 devices is VTERB-BLK-
E3-U4.
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 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
(dynamic puncturing)
See Table 2-4 on
page 17. 1801 3201 1032 29 4 176
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4 on
page 17. 1935 3467 1185 13 4 176
1. Performance and utilization data are generated targeting an LFE2M-35E-7F672C 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 LatticeECP2M family.
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
(dynamic puncturing)
See Table 2-4
on page 17. 1768 3191 1032 29 4 171
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4
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 Syn-
plify Pro D-2009.12L-1 software. Performance may vary when using a different software version or targeting a different device den-
sity or speed grade within the LatticeECP3 family
Lattice Semiconductor Resource Utilization
IPUG32_02.7, June 2010 33 Block Viterbi Decoder User’s Guide
LatticeSC and LatticeSCM FPGAs
Table A-5. Performance and Resource Utilization1
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeSC/M devices is VTERB-BLK-
SC-U4.
LatticeXP FPGAs
Table A-6. Performance and Resource Utilization1
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeXP devices is VTERB-BLK-XM-
U4.
Configuration 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
(dynamic puncturing)
See Table 2-4 on
page 17. 1389 2617 1032 29 4 230
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4 on
page 17. 1743 3227 1186 13 4 224
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.
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
(dynamic puncturing)
See Table 2-4 on
page 17. 1474 2742 1032 29 4 104
IEEE 802.16 2004-OFDM PHY
(fixed puncturing)
See Table 2-4 on
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 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 LatticeXP family.
Lattice Semiconductor Resource Utilization
IPUG32_02.7, June 2010 34 Block Viterbi Decoder User’s Guide
LatticeXP2 FPGAs
Table A-7. Performance and Resource Utilization1
Ordering Part Number
The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeXP2 devices is VTERB-BLK-X2-
U4.
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.
