Turbo Intel FPGA IP User Guide
Version Information
Updated for: |
---|
Intel® Quartus® Prime Design Suite 20.4 |
IP Version 20.4.0 |
1. About the Turbo Intel FPGA IP
Turbo codes are suitable for 3G and 4G mobile communications and satellite communications to help transmitting and receiving messages over noisy channels. You can also use Turbo codes in other applications that require reliable information transfer over bandwidth- or latency-constrained communication links in the presence of data corrupting noise.
1.1. Turbo Intel FPGA IP Features
- General features:
- 3GPP LTE compliant with support for block sizes from 40 to 6,144.
- 3GPP UMTS compliant with support for block sizes from 40 to 5,114.
- C/MATLAB bit-accurate models for performance simulation or RTL test vector generation.
- Decoder features:
- Run time parameters for interleaver size and number of iterations.
- Early termination with cyclical redundancy check (CRC).
- Compile time parameters for the number of parallel engines, input precision.
- Uses MaxLogMAP decoding algorithm.
- Double-buffering for reduced latency real-time applications, which allows the decoder to receive data while processing the previous data block at compile time.
- No external memory required.
- Encoder features:
- Run-time selectable interleaver block sizes.
- Compile time parameters for standard (LTE or UMTS) and parallel encoding engines (1, 4 or 8) for high throughput and low latency.
- Code rate 1/3 only. Use external rate matching for other code rates.
- Double-buffering allows the encoder to receive data while processing the previous data block at compile time.
1.2. Turbo Intel FPGA IP Device Family Support
Intel offers the following device support levels for Intel FPGA IP cores:
- Advance support—the IP is available for simulation and compilation for this device family. FPGA programming file (.pof) support is not available for Quartus Prime Pro Stratix 10 Edition Beta software and as such IP timing closure cannot be guaranteed. Timing models include initial engineering estimates of delays based on early post-layout information. The timing models are subject to change as silicon testing improves the correlation between the actual silicon and the timing models. You can use this IP core for system architecture and resource utilization studies, simulation, pinout, system latency assessments, basic timing assessments (pipeline budgeting), and I/O transfer strategy (data-path width, burst depth, I/O standards tradeoffs).
- Preliminary support—Intel verifies the IP with preliminary timing models for this device family. The IP core meets all functional requirements, but might still be undergoing timing analysis for the device family. You can use it in production designs with caution.
- Final support—Intel verifies the IP with final timing models for this device family. The IP core meets all functional and timing requirements for the device family. You can use it in production designs.
Device Family | Support |
---|---|
Intel® Agilex™ | Advance |
Intel® Stratix® 10 | Final |
Intel® Arria® 10 | Final |
Intel® Cyclone® 10 | Final |
Stratix V | Final |
Arria V | Final |
Cyclone V | Final |
Stratix® IV GT | Final |
Stratix IV GX/E | Final |
Cyclone® IV | Final |
Arria® II GX | Final |
Arria II GZ | Final |
Intel® MAX® 10 FPGA | Final |
Other device families | No support |
1.3. Turbo IP Core Performance and Resource Utilization
Device | Speed Grade | Parameters | ALM | Memory | fMAX1 (MHz) | ||||
---|---|---|---|---|---|---|---|---|---|
Codec Type | Standard | Input Bits | Engines | M20K | M10K | ||||
Intel® Agilex™ | 2 | Encoder | LTE | - | 1 | 529 | 8 | - | 425 |
- | 4 | 900 | 10 | - | 425 | ||||
- | 8 | 1.4K | 19 | - | 425 | ||||
- | - | 529 | 8 | - | 425 | ||||
UMTS | - | 1 | 1.1K | 9 | - | 432 | |||
Decoder | LTE | 6 | 8 | 12.8K | 27 | - | 414 | ||
8 | 8 | 15.2K | 32 | - | 411 | ||||
6 | 16 | 23.4K | 34 | - | 383 | ||||
8 | 16 | 28K | 40 | - | 365 | ||||
UMTS | 6 | 2 | 4.9K | 80 | - | 303 | |||
8 | 2 | 5.5K | 90 | - | 295 | ||||
6 | 4 | 7.2K | 92 | - | 304 | ||||
8 | 4 | 8.1K | 97 | - | 286 | ||||
Intel® Stratix® 10 | 2 | Encoder | LTE | - | 1 | 528 | 8 | - | 405 |
- | 4 | 987 | 10 | - | 411 | ||||
- | 8 | 1.4K | 19 | - | 381 | ||||
UMTS | - | 1 | 1.1K | 9 | - | 330 | |||
- | 1 | 1.1K | 9 | - | 315 | ||||
Decoder | LTE | 6 | 8 | 12.7K | 27 | - | 313 | ||
8 | 8 | 15.2K | 32 | - | 313 | ||||
6 | 16 | 23.2K | 34 | - | 292 | ||||
8 | 16 | 27.8K | 40 | - | 271 | ||||
UMTS | 6 | 2 | 4.8K | 80 | - | 239 | |||
8 | 2 | 5.5K | 90 | - | 230 | ||||
6 | 4 | 7.1K | 92 | - | 239 | ||||
8 | 4 | 8.1K | 97 | - | 225 | ||||
Intel® Arria® 10 | 1 | Encoder | LTE | - | 1 | 476 | 2 | - | 425 |
- | 4 | 902 | 10 | - | 371 | ||||
- | 8 | 1.4K | 10 | - | 371 | ||||
UMTS | - | 1 | 1K | 4 | - | 304 | |||
Decoder | LTE | 6 | 8 | 11K | 27 | - | 323 | ||
8 | 8 | 13K | 32 | - | 331 | ||||
6 | 16 | 19.9K | 34 | - | 311 | ||||
8 | 16 | 23.8K | 40 | - | 298 | ||||
UMTS | 6 | 2 | 4.7K | 71 | - | 228 | |||
8 | 2 | 5.5K | 81 | - | 213 | ||||
6 | 4 | 7.4K | 73 | - | 225 | ||||
8 | 4 | 8.4K | 78 | - | 208 |
1.4. Turbo Code Licensing Disclaimer
France Telecommunication, for itself and certain other parties, claims certain intellectual property rights covering Turbo Codes technology, and has decided to license these rights under a licensing program called the Turbo Codes Licensing Program. Supply of this IP core does not convey a license nor imply any right to use any Turbo Codes patents owned by France Telecommunication, TDF or GET. For information about the Turbo Codes Licensing Program, contact France Telecommunication at the following address:
France Telecommunication R&D
VAT/TURBOCODES
38, rue du Général Leclerc
92794 Issy Moulineaux
Cedex 9
France
1.5. Release Information
Intel® FPGA IP versions match the Intel® Quartus® Prime Design Suite software versions until v19.1. Starting in Intel® Quartus® Prime Design Suite software version 19.2, Intel® FPGA IP has a new versioning scheme.
The Intel® FPGA IP version (X.Y.Z) number can change with each Intel® Quartus® Prime software version. A change in:
- X indicates a major revision of the IP. If you update the Intel® Quartus® Prime software, you must regenerate the IP.
- Y indicates the IP includes new features. Regenerate your IP to include these new features.
- Z indicates the IP includes minor changes. Regenerate your IP to include these changes.
Item | Description |
---|---|
Intel® Quartus® Prime Version | 20.4 |
IP Version | 20.4.0 |
Release Date | 2020.12.14 |
Ordering Code | IP-TURBO (IPR-TURBO) |
2. Getting Started with the Turbo Intel FPGA IP
2.1. Installing and Licensing Intel FPGA IP Cores
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
Location | Software | Platform |
---|---|---|
<drive>:\intelFPGA_pro\quartus\ip\altera | Intel® Quartus® Prime Pro Edition | Windows* |
<drive>:\intelFPGA\quartus\ip\altera | Intel® Quartus® Prime Standard Edition | Windows |
<home directory>:/intelFPGA_pro/quartus/ip/altera | Intel® Quartus® Prime Pro Edition | Linux* |
<home directory>:/intelFPGA/quartus/ip/altera | Intel® Quartus® Prime Standard Edition | Linux |
2.1.1. Intel FPGA IP Evaluation Mode
- Simulate the behavior of a licensed Intel® FPGA IP core in your system.
- Verify the functionality, size, and speed of the IP core quickly and easily.
- Generate time-limited device programming files for designs that include IP cores.
- Program a device with your IP core and verify your design in hardware.
Intel® FPGA IP Evaluation Mode supports the following operation modes:
- Tethered—Allows running the design containing the licensed Intel® FPGA IP indefinitely with a connection between your board and the host computer. Tethered mode requires a serial joint test action group (JTAG) cable connected between the JTAG port on your board and the host computer, which is running the Intel® Quartus® Prime Programmer for the duration of the hardware evaluation period. The Programmer only requires a minimum installation of the Intel® Quartus® Prime software, and requires no Intel® Quartus® Prime license. The host computer controls the evaluation time by sending a periodic signal to the device via the JTAG port. If all licensed IP cores in the design support tethered mode, the evaluation time runs until any IP core evaluation expires. If all of the IP cores support unlimited evaluation time, the device does not time-out.
- Untethered—Allows running the design containing the licensed IP for a limited time. The IP core reverts to untethered mode if the device disconnects from the host computer running the Intel® Quartus® Prime software. The IP core also reverts to untethered mode if any other licensed IP core in the design does not support tethered mode.
When the evaluation time expires for any licensed Intel® FPGA IP in the design, the design stops functioning. All IP cores that use the Intel® FPGA IP Evaluation Mode time out simultaneously when any IP core in the design times out. When the evaluation time expires, you must reprogram the FPGA device before continuing hardware verification. To extend use of the IP core for production, purchase a full production license for the IP core.
You must purchase the license and generate a full production license key before you can generate an unrestricted device programming file. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit.
Intel® licenses IP cores on a per-seat, perpetual basis. The license fee includes first-year maintenance and support. You must renew the maintenance contract to receive updates, bug fixes, and technical support beyond the first year. You must purchase a full production license for Intel® FPGA IP cores that require a production license, before generating programming files that you may use for an unlimited time. During Intel® FPGA IP Evaluation Mode, the Compiler only generates a time-limited device programming file (<project name> _time_limited.sof) that expires at the time limit. To obtain your production license keys, visit the Self-Service Licensing Center.
The Intel® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
2.1.2. Turbo IP Timeout Behavior
For IP cores, the untethered time-out is 1 hour; the tethered time-out value is indefinite. Your design stops working after the hardware evaluation time expires. The Quartus Prime software uses Intel® FPGA IP Evaluation Mode Files (.ocp) in your project directory to identify your use of the Intel® FPGA IP Evaluation Mode evaluation program. After you activate the feature, do not delete these files..When the evaluation time expires, the data output port reset_n goes low, which keeps the IP core permanently in its reset state.
2.2. IP Catalog and Parameter Editor
- Filter IP Catalog to Show IP for active device family or Show IP for all device families. If you have no project open, select the Device Family in IP Catalog.
- Type in the Search field to locate any full or partial IP core name in IP Catalog.
- Right-click an IP core name in IP Catalog to display details about supported devices, to open the IP core's installation folder, and for links to IP documentation.
- Click Search for Partner IP to access partner IP information on the web.
The parameter editor prompts you to specify an IP variation name, optional ports, and output file generation options. The parameter editor generates a top-level Intel® Quartus® Prime IP file (.ip) for an IP variation in Intel® Quartus® Prime Pro Edition projects. This file represents the IP variation in the project, and stores parameterization information.2
2.3. Specifying the IP Core Parameters and Options
Follow these steps to locate, instantiate, and customize an IP core in the parameter editor:
- Create or open an Intel® Quartus® Prime project (.qpf) to contain the instantiated IP variation.
- In the IP Catalog (Tools > IP Catalog), locate and double-click the name of the IP core to customize. To locate a specific component, type some or all of the component’s name in the IP Catalog search box. The New IP Variation window appears.
-
Specify a top-level name for your custom IP variation. Do not
include spaces in IP variation names or paths. The parameter editor saves the IP
variation settings in a file named
<your_ip>
.ip. Click OK. The parameter editor appears.
Figure 4. IP Parameter Editor ( Intel® Quartus® Prime Pro Edition)
-
Set the parameter values in the parameter editor and view the
block diagram for the component. The System
Messages tab at the bottom displays any errors in IP
parameters:
- Optionally, select preset parameter values if provided for your IP core. Presets specify initial parameter values for specific applications.
- Specify parameters defining the IP core functionality, port configurations, and device-specific features.
- Specify options for processing the IP core files in other EDA tools.
Note: Refer to your IP core user guide for information about specific IP core parameters. - Click Generate HDL. The Generation dialog box appears.
- Specify output file generation options, and then click Generate. The synthesis and simulation files generate according to your specifications.
- To generate a simulation testbench, click Generate > Generate Testbench System. Specify testbench generation options, and then click Generate.
- To generate an HDL instantiation template that you can copy and paste into your text editor, click Generate > Show Instantiation Template.
- Click Finish. Click Yes if prompted to add files representing the IP variation to your project.
-
After generating and instantiating your IP variation, make
appropriate pin assignments to connect ports.
Note: Some IP cores generate different HDL implementations according to the IP core parameters. The underlying RTL of these IP cores contains a unique hash code that prevents module name collisions between different variations of the IP core. This unique code remains consistent, given the same IP settings and software version during IP generation. This unique code can change if you edit the IP core's parameters or upgrade the IP core version. To avoid dependency on these unique codes in your simulation environment, refer to Generating a Combined Simulator Setup Script.
2.3.1. IP Core Generation Output ( Intel Quartus Prime Pro Edition)
File Name | Description |
---|---|
<your_ip>.ip | Top-level IP variation file that contains the parameterization of an IP core in your project. If the IP variation is part of a Platform Designer system, the parameter editor also generates a .qsys file. |
<your_ip>.cmp | The VHDL Component Declaration (.cmp) file is a text file that contains local generic and port definitions that you use in VHDL design files. |
<your_ip>_generation.rpt | IP or Platform Designer generation log file. Displays a summary of the messages during IP generation. |
<your_ip>.qgsimc (Platform Designer systems only) | Simulation caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL. |
<your_ip>.qgsynth (Platform Designer systems only) | Synthesis caching file that compares the .qsys and .ip files with the current parameterization of the Platform Designer system and IP core. This comparison determines if Platform Designer can skip regeneration of the HDL. |
<your_ip>.qip | Contains all information to integrate and compile the IP component. |
<your_ip>.csv | Contains information about the upgrade status of the IP component. |
<your_ip>.bsf | A symbol representation of the IP variation for use in Block Diagram Files (.bdf). |
<your_ip>.spd | Input file that ip-make-simscript requires to generate simulation scripts. The .spd file contains a list of files you generate for simulation, along with information about memories that you initialize. |
<your_ip>.ppf | The Pin Planner File (.ppf) stores the port and node assignments for IP components you create for use with the Pin Planner. |
<your_ip>_bb.v | Use the Verilog blackbox (_bb.v) file as an empty module declaration for use as a blackbox. |
<your_ip>_inst.v or _inst.vhd | HDL example instantiation template. Copy and paste the contents of this file into your HDL file to instantiate the IP variation. |
<your_ip>.regmap | If the IP contains register information, the Intel® Quartus® Prime software generates the .regmap file. The .regmap file describes the register map information of master and slave interfaces. This file complements the .sopcinfo file by providing more detailed register information about the system. This file enables register display views and user customizable statistics in System Console. |
<your_ip>.svd |
Allows HPS System Debug tools to view the register maps of peripherals that connect to HPS within a Platform Designer system. During synthesis, the Intel® Quartus® Prime software stores the .svd files for slave interface visible to the System Console masters in the .sof file in the debug session. System Console reads this section, which Platform Designer queries for register map information. For system slaves, Platform Designer accesses the registers by name. |
<your_ip>.v <your_ip>.vhd |
HDL files that instantiate each submodule or child IP core for synthesis or simulation. |
mentor/ | Contains a msim_setup.tcl script to set up and run a ModelSim* simulation. |
aldec/ | Contains a Riviera-PRO* script rivierapro_setup.tcl to setup and run a simulation. |
/synopsys/vcs /synopsys/vcsmx |
Contains a shell script vcs_setup.sh to set up and run a VCS* simulation. Contains a shell script vcsmx_setup.sh and synopsys_sim.setup file to set up and run a VCS* MX simulation. |
/cadence | Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSim simulation. |
/xcelium | Contains an Xcelium* Parallel simulator shell script xcelium_setup.sh and other setup files to set up and run a simulation. |
/submodules | Contains HDL files for the IP core submodule. |
<IP submodule>/ | Platform Designer generates /synth and /sim sub-directories for each IP submodule directory that Platform Designer generates. |
2.4. Simulating Intel FPGA IP Cores
The Intel® Quartus® Prime software provides integration with many simulators and supports multiple simulation flows, including your own scripted and custom simulation flows. Whichever flow you choose, IP core simulation involves the following steps:
- Generate simulation model, testbench (or example design), and simulator setup script files.
- Set up your simulator environment and any simulation scripts.
- Compile simulation model libraries.
- Run your simulator.
For this IP, the Generate Example Design button in IP parameter editor produces RTL, C, and MATLAB files for simulation. The use of these files in each environment is described in the following sub-sections.
2.5. Simulating the Turbo IP with the RTL Simulator
Before simulating, generate the Turbo IP design example from the IP parameter editor.
- To run the simulation with Synopsys VCS®
simulator:
- Run vcsmx_setup.sh
from <example_design_directory>\simulation_scripts\synopsys\vcsmx\
directory by typing the following
commands:
>> source vcsmx_setup.sh >> simv
- Run vcsmx_setup.sh
from <example_design_directory>\simulation_scripts\synopsys\vcsmx\
directory by typing the following
commands:
- To run the simulation with Cadence NCSim®
simulator:
- Run ncsim_setup.sh from
<example_design_directory>\simulation_scripts\cadence\
directory by typing the following
command:
sh ./ncsim_setup.sh USER_DEFINED_ELAB_OPTIONS='"-timescale 1ps/1ps"' USER_DEFINED_SIM_OPTIONS='"-input \"@run; exit\""'
- Run ncsim_setup.sh from
<example_design_directory>\simulation_scripts\cadence\
directory by typing the following
command:
- To run the simulation with Xcelium®
simulator:
- Run xcelium_setup.sh
from <example_design_directory>\simulation_scripts\xcelium\
directory by typing the following
command:
sh ./xcelium_setup.sh USER_DEFINED_ELAB_OPTIONS='"-timescale 1ps/1ps"' USER_DEFINED_SIM_OPTIONS='"-input \"@run; exit\""'
- Run xcelium_setup.sh
from <example_design_directory>\simulation_scripts\xcelium\
directory by typing the following
command:
- To run the simulation with ModelSim®
simulator:
- Run msim_setup.tcl from
<example_design_directory>\simulation_scripts\mentor\
directory by typing the following commands:
do msim_setup.tcl ld run -all
- Run msim_setup.tcl from
<example_design_directory>\simulation_scripts\mentor\
directory by typing the following commands:
- To run the simulation with Aldec®
simulator:
- Run rivierapro_setup.tcl
from <example_design_directory>\simulation_scripts\aldec\
directory by typing the following
commands:
do rivierapro_setup.tcl ld run -all
- Run rivierapro_setup.tcl
from <example_design_directory>\simulation_scripts\aldec\
directory by typing the following
commands:
2.6. Simulating the Turbo IP with the C-Model
Before simulating, generate the Turbo IP design example from the IP parameter editor.
2.6.1. Encoder Simulation
- Go to the <example_design_directory>\c\ directory.
-
Compile
the C
code:
For LTE, type the following command:
>> gcc -lm main_lte_enc.c -o run_enc
For UMTS, type the following command:>> gcc -lm main_umts_enc.c -o run_enc
-
Run the
executable without arguments.
>>./run_enc
Note: The executable reads /test_data/ctc_encoder_input.txt and ./test_data/ctc_encoder_input_info.txt as inputs. The executable generates /test_data/ctc_encoder_output_gold.txt as output. The RTL simulation uses the same input .txt files. The output .txt file provides a golden output, which may be used to check the correctness of the output from RTL simulations.
2.6.2. Decoder Simulation
- Go to the <example_design_directory>\c\ directory.
-
Compile the C code:
For LTE, type the following command:
>> gcc -lm main_lte_dec.c -o run_dec
For UMTS, type the following command:>> gcc -lm main_umts_dec.c -o run_dec
-
Run the executable without arguments.
>>./run_dec
Note: The executable reads /test_data/ctc_input_data.txt and /test_data/ctc_input_info.txt as inputs. The executable generates /test_data/ctc_decoded_output_gold.txt and ctc_output_et_info_gold.txtas output. The RTL simulation uses the same input .txt files. The output .txt file provides a golden output, which may be used to check the correctness of the output from RTL simulations.
2.7. Simulating the Turbo IP with MATLAB
Before simulating, generate the Turbo IP design example from the IP parameter editor.
- Run the following script for
LTE:
main_lte_enc
- Run the following script for
UMTS:
main_umts_enc
- Run the following script for
LTE:
main_lte_dec
- Run the following script for
UMTS:
main_umts_dec
3. Parameter Settings
Parameter | Range | Description |
---|---|---|
Turbo Specification | ||
Standard | LTE or UMTS | Select LTE or UMTS. |
Codec Type | Encoder, Decoder | Select an encoder or decoder. |
Turbo Decoder Options | ||
Number of Processors | 2, 4, 8, 16, 32 Note: The UMTS supports only 2 and 4, and LTE
supports 2, 4, 8, 16, 32.
|
Select the number of engines (N dec) that the decoder uses. The output width (W out) varies depending on the number of engines:
Note: For the UMTS the output width is always
1.
|
Number of LLRs per input | 1 or 2 | The number of data LLR per input symbol
(N
LLR). For two LLR the input
symbols are Z’2 Z2 X2 Z’1 Z1 X1 Note: This parameter is not available if you
select UMTS standard.
|
Width of the input LLRs | 5, 6, 7, 8 | The number of input bits (W LLR) to the decoder. |
Turbo Encoder Options | ||
Parallelism of Encoder | 1, 4, 8 | Selects the number of parallel encoding
engines (N
enc) for LTE turbo encoder only. For UMTS turbo encoder the value of this parameter (N enc) is 1. This parameter is not available in the Intel® Quartus® Prime Standard Edition software IP variations. |
4. Turbo Intel FPGA IP Functional Description
You can parameterize the Turbo IP core as an encoder or a decoder.
4.1. Turbo Encoder
The output from the turbo coder is:
X 0, Z 0, Z’ 0, X 1, Z 1, Z’ 1, ..., X K–1, Z K–1, Z’ K–1
Where:
- Bits X 0, X 1, ..., X K–1 are input to both the first 8-state constituent encoder and the internal interleaver (K is the number of bits).
- Bits Z 0, Z 1, ..., Z K–1 and Z’ 0, Z’ 1, ..., Z’ K–1 are output from the first and second 8-state constituent encoders.
- The bits output from the internal interleaver (and input to the second 8-state constituent encoder) are X’ 0, X’ 1, ..., X’ K–1.
- Additionally, encoder outputs 12 termination bits, X K , X K+1, X K+2, X’ K, X’ K+1, X’ K+2, Z K, Z K+1, Z K+2, Z’ K, Z’ K+1, Z’ K+2.
4.1.1. Turbo Encoder Data Format
The required input data ordering for a block of size K is: X 0, X 1, X 2, . . . . X K - 1. The output data is three bits wide.
Output Data | sink_data | ||
---|---|---|---|
Nenc = 8 | Nenc = 4 | Nenc = 1 | |
0 | X 7 X 6 X 5 X 4 X 3 X 2 X 1 X 0 | X 3 X 2 X 1 X 0 | X 0 |
1 | X 15 X 14 X 13 X 12 X 11 X 10 X 9 X 8 | X 7 X 6 X 5 X 4 | X 1 |
... | ... | ... | .. |
K - 1 | - | - | X K - 1 |
K/4-1 | - | X K-1 X K-2 X K-3 X K-4 | - |
K/8-1 | X K-1 X K-2 X K-3 X K-4 X K-5 X K-6 X K-7 X K-8 | - | - |
Output Data | source_data | ||
---|---|---|---|
2 | 1 | 0 | |
0 | Z ’0 | Z 0 | X 0 |
1 | Z ’1 | Z 1 | X 1 |
... | ... | ... | .. |
K - 1 | Z ’ K - 1 | Z K - 1 | X K - 1 |
K | X K + 1 | Z K | X K |
K + 1 | Z K + 2 | X K + 2 | Z K + 1 |
K + 2 | X ’ K + 1 | Z ’ K | X ’ K |
K + 3 | Z ’ K + 2 | X ’ K + 2 | Z ’ K + 1 |
Output Data | source_data | ||
---|---|---|---|
11...8 | 7...4 | 3...0 | |
0 | Z ’3 Z ’2 Z ’1 Z’0 | Z 3 Z 2 Z 1 Z 0 | X 3 X 2 X 1 X 0 |
1 | Z ’7 Z ’6 Z ’5 Z’4 | Z 7 Z 6 Z 5 Z 4 | X7X 6 X 5 X 4 |
... | ... | ... | .. |
K / 4 - 1 | Z ’K-1 Z ’K-2 Z ’K-3 Z’K-4 | Z K-1 Z K-2 Z K-3 Z K-4 | X K-1 X K-2 X K-3 X K-4 |
K / 4 | Z ’K+2 X ’K+1 Z K+2 X K+1 | X ’K+2 Z ’K X K+2 Z K | Z ’K+1 X ’K Z K+1 X K |
Output Data | source_data | ||
---|---|---|---|
23...16 | 15...8 | 7...0 | |
0 | Z ’7 Z ’6 Z ’5 Z’4 Z’3 Z’2 Z’1 Z’0 | Z 7 Z 6 Z 5 Z 4 Z 3 Z 2 Z 1 Z 0 | X 7 X 6 X 5 X 4 X 3 X 2 X 1 X 0 |
1 | Z ’15 Z ’14 Z ’13 Z’12 Z’11 Z’10 Z’9 Z’8 | Z 15 Z 14 Z 13 Z 12 Z 11 Z 10 Z 9 Z 8 | X 15 X 14 X 13 X 12 X 11 X 10 X 9 X 8 |
... | ... | ... | .. |
K / 8 - 1 | Z ’K-1 Z ’K-2 Z ’K-3 Z’K-4 Z’K-5 Z’K-6 Z’K-7 Z’K-8 | Z K-1 Z K-2 Z K-3 Z K-4 Z K-5 Z K-6 Z K-7 Z K-8 | X K-1 X K-2 X K-3 X K-4 X K-5 X K-6 X K-7 X K-8 |
K / 8 | 4'bx Z ’K+2 X ’K+1 Z K+2 X K+1 | 4'bx X ’K+2 Z ’K X K+2 Z K | 4'bx Z ’K+1 X ’K Z K+1 X K |
4.1.2. Turbo Encoder Latency Calculation
For example:
- When K = 6144, and Nenc = 8, D = 6144/8 +14 = 782
- When K = 40, and Nenc = 1, D = 40 + 14 = 54
You can calculate the encoding latency (the time taken by the encoder to encode an entire block) using the following equation:
L= D/f s
Where f is the system clock speed.
4.2. Turbo Decoder
The Turbo decoder supports the MaxLogMAP decoding algorithm. This algorithm is a simplified version of LogMAP that uses less logic resource and offers slightly reduced BER performance relative to LogMAP.
4.2.1. Turbo Decoder Data Format
Input Data | sink_data | ||
---|---|---|---|
3N - 1 down to 2N | 2N - 1 down to N | N - 1 down to 0 | |
0 | Z ’0 | Z 0 | X 0 |
1 | Z ’1 | Z 1 | X 1 |
... | ... | ... | ... |
K - 1 | Z ’ K - 1 | Z K - 1 | X K - 1 |
K | X K + 1 | Z K | X K |
K + 1 | Z K + 2 | X K + 2 | Z K + 1 |
K + 2 | X ’ K + 1 | Z ’ K | X ’ K |
K + 3 | Z ’ K + 2 | X ’ K + 2 | Z ’ K + 1 |
The Turbo decoder requires all data to be in the log-likelihood format. The connected system must provide soft information, including parity 1 and parity 2 bit sequences according to the following equation:
L(x) = log[P(x=1)/(x=0)]
The log-likelihood value is the logarithm of the probability that the received bit is a 1, divided by the probability that this bit is a 0. It is represented as a two’s complement number. A value of zero indicates equal probability of a 1 and a 0, which you should use for depuncturing. The decoder does not use the most negative two’s complement number, which means the representation is balanced.
Input (3 downto 0) | Value |
---|---|
0111 | Most likelihood of a 1 |
... | ... |
0001 | Lowest likelihood of a 1 |
0000 | Equal probability of a 0 or 1 |
1111 | Lowest likelihood of a 0 |
... | ... |
1001 | Most likelihood of a 0 |
1000 | Not used |
Output
The number of output bits can be 1 or 8 bits. For 1 bit, the ordering is: X 0, X 1, X 2, . . . . X K-1
Output Order | source_data | |||||||
---|---|---|---|---|---|---|---|---|
7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
1 | X 7 | X 6 | X 5 | X 4 | X 3 | X 2 | X 1 | X 0 |
2 | X 15 | X 14 | X 13 | X 12 | X 11 | X 10 | X 9 | X 8 |
... | ... | ... | ... | ... | ... | ... | ... | ... |
K/8 | X K - 1 | X K – 2 | X K – 3 | X K – 4 | X K – 5 | X K – 6 | X K – 7 | X K – 8 |
4.2.2. CRC24A or CRC24B Early Termination
The IP core checks the CRC checksum that the decoder generates after every iteration. Turbo decoding stops as soon as the CRC is successful. turbo decoding does not continue until the maximum number of iterations specified at the input ports. The gains depend on the signal-to-noise ration (SNR) of the received data block, block size, and the maximum number of iterations you specify.
4.2.3. Decoder Latency Calculation
The following calculations assume no early termination for the worst case latency.
You can calculate the decoding delay D using one of the following equations:
- If K < 264: D = 26 + (2 × f(K,N) + 14) × 2 × I
- If K > 264, D = 26 + (f(K,N) + 46) × 2 × I
where:
- K is the block size
- I is the number of decoding iterations
- N dec is the number of engines specified in the decoder
- f(K,N dec) = K/N dec if K is divisible by N dec.
- f(K,N dec) = K/16 if K is not divisible by N dec, but it is divisible by 16.
- f(K,N dec) = K/8 in all other conditions.
For UMTS, f(K,N dec) = ceil(K/N dec)
For example:
- D = 26 + (6144/8 + 46) × 2 × 8 = 13,050, if K = 6144, N = 8, I = 8.
- D = 26 + (2 × 40/8 + 14) × 2 × 8 = 410, if K = 40, N = 8, I = 8.
You can calculate the decoding latency (the time the decoder takes to decode an entire block to the decoded data is ready for output) using the following equation:
L = D/f s
Where f is the system clock speed.
4.2.4. Error Correction Performance for the Turbo Decoder
4.3. Turbo IP Core Interfaces and Signals
Signal | Direction | Description |
---|---|---|
clk | Input | Clock signal that clocks all internal registers. |
reset_n | Input | Active low reset signal. The IP core must always be reset before receiving data. If the megafunction is not reset, the Turbo encoder may produce unexpected results because of feedback signals. |
sink_blk_size | Input | Specifies the incoming block size. This needs to be held throughout the whole incoming block, from sop to eop. |
sink_data | Input | Input data. |
sink_eop | Input | Indicates the end of an incoming packet. |
sink_sop | Input | Indicates the start of an incoming packet. |
sink_valid | Input | Asserted when data atsink_data is valid. When you deassert sink_valid, the IP core stops processing until you reassert sink_valid. |
source_ready | Input | Asserted by the downstream module if it cannot accept data. |
sink_error | Input | Error signal indicating Avalon-ST protocol violations on input side. |
sink_ready | Output | Indicates when the IP core can accept data. |
source_blk_size | Output | Specifies the outgoing block
size,
which is equal to K / N
enc +
ceil (4 / N
enc).
Valid at source_sop. |
source_data_s | Output | Output data. |
source_eop | Output | Indicates the end of an outgoing packet. |
source_error | Output |
Error signal indicating Avalon-ST protocol violations on source side:
Other types of errors may also be marked as 11. |
source_sop | Output | Indicates the start of an outgoing packet. |
source_valid | Output | Asserted by the IP core when valid data is available to output. |
Signal | Direction | Description |
---|---|---|
clk | Input | Clock signal that clocks all internal registers. |
reset_n | Input | Active low reset signal. You must always reset the IP core before it receives data. If not reset, the Turbo decoder may produce unexpected results because of feedback signals. |
CRC_pass | Output |
Indicates whether CRC was successful:
Note: This
signal is present only in LTE mode.
|
CRC_type | Output |
Indicates the type of CRC that was used for the current data block:
Note: This signal is present only in LTE mode.
|
sel_CRC24A | Input |
Specifies the type of CRC that you need for the current data block:
Note: This signal is present only in LTE mode.
|
sink_blk_size | Input | Specifies the incoming block size. This signal needs to be held throughout the whole incoming block from SOP to EOP. |
sink_data | Input | Input data. |
sink_eop | Input | Indicates the end of an incoming packet. |
sink_error | Input | Error signal indicating Avalon-ST protocol violations on input side. |
sink_max_iter | Input | Specifies the maximum number of half-iterations. It must be even numbers for UMTS. |
sink_ready | Output | Indicates when the IP core can accept data. |
sink_sop | Input | Indicates the start of an incoming packet. |
sink_valid | Input | Assert when data at sink_data is valid. When sink_valid is not asserted, processing stops until you reassert sink_valid. |
source_blk_id | Output | Specifies the outgoing block ID. |
source_blk_size | Output | Specifies the outgoing block size. |
source_data_s | Output | Output data. |
source_eop | Output | Indicates the end of an outgoing packet. |
source_error | Output |
Error signal indicating Avalon-ST protocol violations on source side:
Other types of errors may also be marked as 11. |
source_iter | Output | Shows the number of half iterations after which the Turbo decoder stops processing the current data block. LTE only. |
source_ready | Input | Asserted by the downstream module if it can accept data. |
source_sop | Output | Indicates the start of an outgoing packet. |
source_valid | Output | Asserted by the IP core when there is valid data to output. |
Signals in Platform Designer (Standard) Systems
Platform Designer (Standard) systems instantiate all Turbo IP core signals as part of the Avalon-ST data bus.
Bits | Signal |
---|---|
N enc + 12:N enc | sink_blk_size |
N enc -1:0 | sink_data |
Bits | Signal |
---|---|
3 *N enc+12:3*N enc | source_blk_size |
3*N enc-1:0 | source_data |
Bits | Signal |
---|---|
3*WLLR*NLLR+18 | Sel_CRC24A (LTE only) |
3*WLLR*NLLR+17:3*WLLR*NLLR+13 | sink_max_iter |
3*WLLR*NLLR+12:3*WLLR*NLLR | sink_blk_size |
3*WLLR*NLLR-1:0 | sink_data |
Bits | Signal |
---|---|
Wout+19 | CRC_Pass |
Wout+18 | CRC_type |
Wout+17:Wout+13 | source_iter |
Wout+12:Wout | source_blk_size |
Wout-1:0 | source_data |
Bits | Signal |
---|---|
13:1 | source_blk_size |
0 | source_data |
4.3.1. Packet Format Errors
- Error code "01" indicates missing sink_sop.
- Error code "10" indicates missing sink_eop.
- Error code "11" indicates unexpected sink_sop or sink_eop.
- Default "00" indicates no errors.
- If error_found= 00, sink_error= any, then the source_error= 00.
- If error_found= 01, sink_error= 00 or 01, then the source_error= 01
- If error_found= 01, sink_error= 10 or 11, then the source_error= 11.
- If error_found= 10, sink_error= 00 or 10, then the source_error= 10.
- If error_found= 10, sink_error= 10 or 11, then the source_error= 11.
- If error_found= 11, sink_error= any, then the source_error= 11.
4.4. Turbo Throughput
You can calculate the throughput using the following equation:
T = K/D * frequency (bits per second)
Encoder throughput calculation example:
- When K = 6144, N enc = 8, frequency = 300 MHz, Throughput = 6144/782 x 300M = 2.36 Gbps
- When K = 40, N enc = 1, frequency = 300 MHz, Throughput = 40/56 x 300M = 214.3 Mbps
- When K = 6144, N dec = 8, I = 8, frequency = 300 MHz, Throughput = 6144/13,050 x 300M = 141.2 Mbps
- When K = 40, N dec = 8, I = 8, frequency = 300 MHz, Throughput = 40/410 x 300M = 29.3 Mbps
A. Turbo IP Core User Guide Document Archives
IP versions are the same as the Intel® Quartus® Prime Design Suite software versions up to v19.1. From Intel® Quartus® Prime Design Suite software version 19.2 or later, IP cores have a new IP versioning scheme.
Intel® Quartus® Prime Version | IP Core Version | User Guide |
---|---|---|
15.1 | - | Turbo IP Core User Guide |
5. Document Revision History for Turbo Intel FPGA IP User Guide
Document Version | Intel® Quartus® Prime Version | IP Version | Changes |
---|---|---|---|
2020.12.14 | 20.4 | 20.4.0 |
|
Date | Version | Changes |
---|---|---|
2017.11.06 | 17.1 |
|
2016.05.06 | 16.0 | Corrected features list. |
2015.11.11 | 15.1 |
|
2015.11.01 | 15.1 | Initial release |