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 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- IEEE 2004-OFDM IEEE 802.16- 802.16 DVB-S PHY 2004-OFDM 2004- SC IEEE (dynamic PHY (fixed PHY 3GPP 802.11A puncturing) puncturing) FPGA Families Supported LatticeEC/ECP/XP Core LFEC1E LFEC10E LFEC3E LFEC3E LFEC6E Requirements Minimal Device Needed LFECP6E LFECP10E LFECP6E LFECP6E LFECP6E LFXP3C LFXP10C LFXP3C LFXP3C LFXP6C Targeted Device LFEC20E-5F672C/ LFECP20E-5F672C/ LFXP20E-5F256C Resource LUTs 500 9950 2600 2750 3300 Utilization sysMEM EBRs 2 16 4 4 4 Registers 250 3200 900 1050 1200 Lattice Implementation Diamond® 1.0 or ispLEVER® 8.1 Design Tool Synthesis Synopsys® Synplify® Pro for Lattice D-2009.12L-1 Support Aldec® Active-HDL® 8.2 Lattice Edition Simulation Mentor Graphics® ModelSim® SE 6.3F IPUG32_02.7, June 2010 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-OFDM IEEE 802.16- IEEE 802.16 DVB-S PHY 2004-OFDM 2004- SC IEEE (dynamic PHY (fixed PHY 3GPP 802.11A puncturing) puncturing) FPGA Families Supported LatticeECP2/ECP2M/XP2 Core LFE2-6E LFE2-12E LFE2-6E LFE2-6E LFE2-6E Requirements Minimal Device Needed LFE2M20E LFE2M20E LFE2M20 LFE2M20E LFE2M20E E LFXP2-5E LFXP2-17E LFXP2-5E LFXP2-5E LFXP2-5E Targeted Device LFE2-50E-7F484C/ LFE2M35E-7F672C/ LFXP2-30E-7F484C Resource LUTs 500 11800 3050 3250 3500 Utilization sysMEM EBRs 2 16 4 4 4 Registers 250 3200 900 1050 1200 Lattice Implementation Diamond 1.0 or ispLEVER 8.1 Design Tool Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1 Support 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- IEEE IEEE 2004-OFDM 802.16- 802.16 DVB-S PHY 2004-OFDM 2004- SC IEEE (dynamic PHY (fixed PHY 3GPP 802.11A puncturing) puncturing) Core FPGA Families Supported LatticeSC/SCM Requirements Minimal Device Needed LFSC3GA15E/LFSCM3GA15EP1 Targeted Device LFSC3GA25E-7F900C/ LFSCM3GA25EP1-7F900C Resource LUTs 450 9450 2450 2650 3250 Utilization sysMEM EBRs 2 16 4 4 4 Registers 250 3400 900 1050 1200 Lattice Implementation Diamond 1.0 or ispLEVER 8.1 Design Tool Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1 Support Aldec Active-HDL 8.2 Lattice Edition Simulation Mentor Graphics ModelSim SE 6.3F IPUG32_02.7, June 2010 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- IEEE IEEE 2004-OFDM 802.16- 802.16 DVB-S PHY 2004-OFDM 2004- SC IEEE (dynamic PHY (fixed PHY 3GPP 802.11A puncturing) puncturing) Core FPGA Families Supported LatticeECP3 Requirements Minimal Device Needed LFE3-35EA Targeted Device LFE3-95E-8FN672CES Resource LUTs 500 11750 3050 3200 3500 Utilization sysMEM EBRs 2 16 4 4 4 Registers 250 3200 900 1050 1200 Lattice Implementation Diamond 1.0 or ispLEVER 8.1 Design Tool Synthesis Synopsys Synplify Pro for Lattice D-2009.12L-1 Support Aldec Active-HDL 8.2 Lattice Edition Simulation Mentor Graphics ModelSim SE 6.3F Features (cid:129) Compatible with IEEE 802.16-2004 SC PHY/ OFDM PHY, IEEEE802.11a, 3GPP, 3GPP2, and DVB standards (cid:129) 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 (cid:129) Variable constraint length from 3 to 9 (cid:129) Supports dynamically variable code rates and puncture patterns (cid:129) Dynamic BER estimation option (cid:129) One-clock synchronous design (cid:129) Hard or parameterizable soft decision decoding. Hard and soft decision for non-punctured codes and soft deci- sion for punctured codes (cid:129) Fully parallel or hybrid implementations. For a hybrid implementation, the degree of parallelism is parameteriz- able (cid:129) Parameterizable trace-back length (cid:129) Signed and unsigned representations for soft decision data (cid:129) Supports parameterized puncturing patterns (cid:129) Supports both continuous and block data input (cid:129) Supports both Tail Biting and Zero Flushing block convolutional codes (cid:129) 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 dout din2 outvalid din3 obvalid din4 din5 ber din6 bervalid clk Block rfib rstn Viterbi Decoder pbstart ibstart ibend ppset inrate outrate pp0 pp1 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 Transmitted Convolutional Block Viterbi Received Modulator Channel Demodulator Data Stream Encoder Decoder 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 a a a a a a a 0 1 2 3 4 5 6 i i i i i i i 0 1 2 3 4 5 6 b b b b b b b 0 1 2 3 4 5 6 Puncture pattern Puncture pattern superimposed Final punctured output 1 0 1 a a a a a a a 0 1 2 3 4 5 6 a b b a a b b a 0 0 1 2 3 3 4 5 1 1 0 b b b b b b b 0 1 2 3 4 5 6 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. IPUG32_02.7, June 2010 8 Block Viterbi Decoder User’s Guide

Lattice Semiconductor Functional Description Figure 2-5. Trellis Tree 0/00 0/00 0/00 00 1/00 1/00 1/00 0/01 0/01 0/01 01 1/01 1/01 1/01 0/10 0/10 0/10 10 1/10 1/10 1/10 0/11 0/11 0/11 1/11 1/11 1/11 11 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 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 BER BER din BMU ACS TBU dout MMU 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 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. 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 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 Puncturing Termination Number of Mode Tracebacks 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 n Not Applicable IPUG32_02.7, June 2010 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 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 Signed Binary Unsigned Offset Data Interpretation Data Interpretation 111 -3 (strong logic 1) 111 7 (strong logic 1) 110 -2 110 6 101 -1 (weaker logic 1s) 101 5 (weaker logic 1s) 100 -0 100 4 000 0 011 3 001 1 (weaker logic 0s) 010 2 (weaker logic 0s) 010 2 001 1 011 3 (strong logic 0) 000 0 (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 sum- marized in Table 2-3. 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 “Punctured block start” signal to indicate the start of a new block of punctured pbstart 1 I data. This signal is not available while decoding non-punctured codes. Input block start signal. This must be pulled high when the first data of a block is ibstart 1 I applied on the input port. This port is available for block decoding only. Input block end signal. This signal must be pulled high to indicate the last data ibend 1 I of a block being applied on the input port. This port is available for block decod- ing only. din0, din1, Data input buses – The buses become one bit inputs for hard decision decoding din2, din3, 1 or 3 and equals to the soft width for soft decision decoding. The number of buses is 1 I din4, din5, to 8 (each) for punctured codes and n for non-punctured codes, where n is the code rate din6 factor, from 2 to 7. Input rate of the convolutional code for next block. This port is available only in inrate 1-4 I dynamic puncturing mode. Output rate of the convolutional code for next block. This port is available only in outrate 2-5 I dynamic puncturing mode. IPUG32_02.7, June 2010 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 Puncture pattern 0 of the convolutional code for next block. This port is available pp0 1-12 I only in dynamic puncturing mode. Puncture pattern 1 of the convolutional code for next block. This port is available pp1 1-12 I only in dynamic puncturing mode. Puncture rate and puncture pattern set signal. The new input rate, output rate ppset 1 I 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. Output block valid signal. This signal remains high for the entire duration of the obvalid 1 O 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. 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 bervalid 1 O Period), is the duration over which BER is computed. This port is available for continuous decoding only. “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 rfib 1 O 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). 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-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. 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 1 2 3 4 5 6 7 8 9 10 11 ... output latency outvalid dout x x x x x x x 1 2 3 4 5 6 Figure 2-8. Timing Diagram for a Continuous, Parallel, Punctured (Rate=2/3) Decoder clk pbstart din0 x 1 2 3 4 5 6 x x x x x x output latency outvalid dout x x x x x x x 1 2 x 4 5 x x Figure 2-9. Timing Diagram for a Continuous, Hybrid (Two Cycles), Non-punctured Decoder clk din0 din1 x 1 2 3 4 5 6 ... output latency outvalid dout x x x x 1 2 3 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 output latency outvalid dout x x x 1 2 x 4 IPUG32_02.7, June 2010 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 1 2 ... m ... BL x x 1 2 3 ... ibstart ibend L L rfib outvalid output latency dout x x x x ... x x x x 1 2 ... m 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 6 BL-1 BL 1 2 rfib dout 1 2 3 x 5 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 1 2 3 4 5 IEEE 802.16- IEEE 802.16- IEEE 802.16 DVB-S, IEEE 2004-OFDM PHY Compatible Standard 3GPP 2004-OFDM PHY 2004- SC PHY 802.11A (dynamic (fixed puncturing) puncturing) Primary Options Constraint length (K) 3 9 7 7 7 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 2 2 - 2 2 Puncture Settings Puncturing Fixed None None Dynamic Fixed 10 10101 Puncture Pattern — — Through Port 11 11010 Max Input Rate — — — 5 — Max Output Rate — — — 6 — Generator Polynomials Radix Octal Octal Octal Octal Octal GP0, GP1 (GP2,... 7 561 171 171 171 8 8 8 8 8 N/A) 5 753 133 133 133 8 8 8 8 8 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 3 3 3 3 4 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 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 1/2, 1/3,...,1/7 for Non-Punctured Decoder Code Rate (k/n) 2/3 2/3, 3/4,..., 12/13 for Punctured Decoder Operation Mode Continuous/Block Block Traceback Length 3K to 14K 30 Block Options Termination Mode Zero Flushing/Tail Biting Tail Biting Number of Tracebacks 1, 2 - Puncture Settings Puncturing None/Fixed/Dynamic Fixed 11 Puncture Pattern PP0 and PP1 are each k bits wide binary patterns 10 1 to 12 when Number of Tracebacks = 2 Max Input Rate — 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 7 GP0, GP1, GP2, GP3, GP4, GP5, GP6 K bits wide number for each polynomial 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 — 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 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 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 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: (cid:129) Project Path – Path to the directory where the generated IP files will be loaded. (cid:129) File Name – “username” designation given to the generated IP core and corresponding folders and files. (cid:129) (Diamond) Module Output – Verilog or VHDL. • (ispLEVER) Design Entry Type – Verilog HDL or VHDL. (cid:129) 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. (cid:129) 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 infor- mation 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 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 The ngo files provide the synthesized IP core. *.ngo This file contains the IPexpress tool options used to recreate or modify the core in the <username>.lpc IPexpress tool. Created when GUI “Generate” button is pushed, invokes generation, may be run from <username>_generate.tcl command line. <username>_generate.log IPexpress scripts log file. <username>_gen.log IPexpress IP generation log file IPUG32_02.7, June 2010 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 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). 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 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. 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 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 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. (cid:129) For USA & Canada: 1-800-LATTICE (528-8423) (cid:129) 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. (cid:129) For Asia: +86 21 52989090 E-mail Support (cid:129) techsupport@latticesemi.com (cid:129) 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 (cid:129) HB1000, LatticeEC/ECP Family Handbook IPUG32_02.7, June 2010 29 Block Viterbi Decoder User’s Guide

Lattice Semiconductor Support Resources LatticeECP2M (cid:129) HB1003, LatticeECP2M Family Handbook LatticeECP3 (cid:129) HB1009, LatticeECP3 Family Handbook LatticeSC/M (cid:129) DS1004, LatticeSC/M Family Data Sheet LatticeXP (cid:129) HB1001, LatticeXP Family Handbook LatticeXP2 (cid:129) DS1009, Lattice XP2 Datasheet Revision History Document IP Date Version Versions Change Summary — — 4.0 Previous Lattice releases. 02.3 4.1 Updated appendices. Added support for LatticeECP2M device December 2006 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 May 2009 device family. June 2010 02.7 4.5 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.” 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 sysMEM™ f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 280 457 232 11 2 126 page 17. See Table 2-4 on 3GPP 5041 9922 3160 13 16 101 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1310 2562 864 10 4 106 page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1474 2742 1032 29 4 108 (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1735 3254 1185 13 4 108 (fixed puncturing) page 17. 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 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 291 469 232 11 2 207 page 17. See Table 2-4 on 3GPP 6345 11747 3160 13 16 138 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1636 3017 864 10 4 178 page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1801 3201 1032 29 4 175 (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1935 3467 1185 13 4 129 (fixed puncturing) page 17. 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. 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-BLK- P2- U4. LatticeECP2M FPGAs Table A-3. Performance and Resource Utilization1 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 291 469 232 11 2 211 page 17. See Table 2-4 on 3GPP 6345 11747 3160 13 16 135 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1636 3017 864 10 4 179 page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1801 3201 1032 29 4 176 (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1935 3467 1185 13 4 176 (fixed puncturing) page 17. 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. 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 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 IEEE 802.16a 2004-SC-PHY 285 469 232 11 2 187 on page 17. See Table 2-4 3GPP 6349 11736 3159 13 16 132 on page 17. See Table 2-4 DVB-S, IEEE 802.11a 1626 3011 864 10 4 168 on page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 1768 3191 1032 29 4 171 (dynamic puncturing) on page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 1935 3485 1185 13 4 146 (fixed puncturing) on page 17. 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 Ordering Part Number The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeECP3 devices is VTERB-BLK- E3-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 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 263 433 233 11 2 261 page 17. See Table 2-4 on 3GPP 4923 9426 3391 13 16 207 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1239 2438 864 10 4 236 page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1389 2617 1032 29 4 230 (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1743 3227 1186 13 4 224 (fixed puncturing) page 17. 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-BLK- SC-U4. LatticeXP FPGAs Table A-6. Performance and Resource Utilization1 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 280 457 232 11 2 116 page 17. See Table 2-4 on 3GPP 5041 9922 3160 13 16 92 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1310 2562 864 10 4 101 page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1474 2742 1032 29 4 104 (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM PHY See Table 2-4 on 1735 3254 1185 13 4 100 (fixed puncturing) page 17. 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. Ordering Part Number The Ordering Part Number (OPNs) for the Block Viterbi Decoder IP on the LatticeXP devices is VTERB-BLK-XM- U4. 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 sysMEM f MAX Configuration Parameters SLICEs LUTs Registers IOB EBRs (MHz) See Table 2-4 on IEEE 802.16a 2004-SC-PHY 291 469 232 11 2 183 page 17. See Table 2-4 on 3GPP 6345 1147 3160 13 16 128 page 17. See Table 2-4 on DVB-S, IEEE 802.11a 1636 3017 864 10 4 160 page 17. IEEE 802.16 2004-OFDM See Table 2-4 on 1801 3201 1032 29 4 153 PHY (dynamic puncturing) page 17. IEEE 802.16 2004-OFDM See Table 2-4 on 1935 3467 1185 13 4 136 PHY (fixed puncturing) page 17. 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-X2- U4. IPUG32_02.7, June 2010 34 Block Viterbi Decoder User’s Guide