- Avalon® Streaming (Avalon-ST) interfaces
- DSP Builder for Altera® FPGAs ready
- Testbenches to verify the IP core
- IP functional simulation models for use in Altera-supported VHDL and Verilog HDL simulators
- High-speed parallel architecture:
- Performance of over 250 megabits per second (Mbps)
- Fully parallel operation
- Optimized block decoding and continuous decoding
- Low to medium-speed, hybrid architecture:
- Configurable number of add compare and select (ACS) units
- Memory-based architecture
- Wide range of performance; wide range of logic area
- Fully parameterized Viterbi decoder, including:
- Number of coded bits
- Constraint length
- Number of soft bits
- Traceback length
- Polynomial for each coded bit
- Variable constraint length
- Trellis coded modulation (TCM) option
Altera offers the following device support levels for Altera FPGA IP cores:
- Advance support—the IP core 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—Altera verifies the IP core 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—Altera verifies the IP core 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.
|Arria® II GX||Final|
|Arria II GZ||Final|
|Intel® Arria® 10||Final|
|Intel® Cyclone® 10||Final|
|Intel® MAX® 10 FPGA||Final|
|Stratix® IV GT||Final|
|Stratix IV GX/E||Final|
|Intel® Stratix® 10||Advance|
|Other device families||No support|
|Release Date||November 2017|
|Ordering Code||IP-VITERBI/HS (parallel architecture) IP-VITERBI/SS (hybrid architecture)|
Altera verifies that the current version of the Quartus Prime software compiles the previous version of each IP core. Altera does not verify that the Quartus Prime software compiles IP core versions older than the previous version. The Altera FPGA IP Release Notes lists any exceptions.
The typical expected performance for a hybrid Viterbi IP core uses the Quartus Prime software with the Arria V (5AGXFB3H4F40C4), Cyclone V (5CGXFC7D6F31C6), and Stratix V (5SGSMD4H2F35C2) devices and the following parameters:
- v = 6 × L
- softbits = 3
- N = 2
- v is the traceback length
- L is the constraint length
- N is the number of coded bits
- A is the number of ACS units
The typical expected performance for a parallel Viterbi IP core uses the Quartus Prime software with the Arria V (5AGXFB3H4F40C4), Cyclone V (5CGXFC7D6F31C6), and Stratix V (5SGSMD4H2F35C2) devices. The following parameters apply:
- v = 6 ×L
- N = 2
- v is the traceback length
- L is the constraint length
- N is the number of coded bits
|softbits||L||Optimization||Best State Finder||M10K||M20K||Primary||Secondary|
The Intel® Quartus® Prime software installs IP cores in the following locations by default:
|<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|
- 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.
Altera® 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 or contact your local Intel FPGA representative.
The Altera® FPGA Software License Agreements govern the installation and use of licensed IP cores, the Intel® Quartus® Prime design software, and all unlicensed IP cores.
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 decbit signal goes low .
- 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.
The parameter editor generates a top-level Quartus IP file (.qip) for an IP variation in Intel® Quartus® Prime Standard Edition projects. These files represent the IP variation in the project, and store parameterization information.
- 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.
Set the parameter values in the parameter editor and view the
block diagram for the component. The Parameterization Messages tab at the bottom displays any errors
in IP parameters:
Note: Refer to your IP core user guide for information about specific IP core 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.
- 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.
and instantiating your IP variation, make appropriate pin assignments to
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.
|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.
Contains all information to integrate and compile the IP component.
|<your_ip>.csv||Contains information about the upgrade status of the IP component.|
A symbol representation of the IP variation for use in Block Diagram Files (.bdf).
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.|
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.|
Contains a msim_setup.tcl script to set up and run a ModelSim simulation.
Contains a Riviera*-PRO script rivierapro_setup.tcl to setup and run a simulation.
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.
Contains a shell script ncsim_setup.sh and other setup files to set up and run an NCSIM 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.|
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.
This IP core supports DSP Builder for Altera® FPGAs. Use the DSP Builder for Altera® FPGAs flow if you want to create a DSP Builder for Altera® FPGAs model that includes an IP core variation; use IP Catalog if you want to create an IP core variation that you can instantiate manually in your design.
The continuous decoder processes a number of symbols greater than the traceback length. When the decoder traces back the number of bits (traceback length), it delivers output bits. This behavior changes when you assert the end of packet (EOP) signal. The decoder then switches to block decoding, starting traceback from the last symbol or state. The tr_init_state signal indicates the end state that starts the traceback operation. For block decoding Altera recommends you indicate the end state of the tail bits (usually zero) and set the tb_type signal to 1.
Bandwidth-constrained channels operate in the region R/W > 1, where R = data rate and W = bandwidth available. For such channels, digital communication systems use bandwidth efficient multilevel phase modulation. For example, phase shift keying (PSK), phase amplitude modulation (PAM), or quadrature amplitude modulation (QAM).
When you apply TCM to a bandwidth-constrained channel, you see a performance gain without expanding the signal bandwidth. An increase in the number of signal phases from four to eight requires approximately 4dB in additional signal power to maintain the same error rate. Hence, if TCM is to provide a benefit, the performance gain of the rate 2/3 code must overcome this 4dB penalty. If the modulation is an integral part of the encoding process and is designed in conjunction with the code to increase the minimum Euclidian distance between the pairs of coded signals, the loss from the expansion of the signal set is easily overcome and significant coding gain is achieved with relatively simple codes.
Any bandwidth-constrained system benefits from this technique, for example, satellite modem systems. The TCM Viterbi decoder only supports N = 2 (only mother code rates of 1/2).
The specific mapping is not important. You can derive other mappings by permutating subsets in a way that preserves the main property of increased minimum distance among the subsets. However, you can create any other mapping, including symbol mappings for 8-PSK, 16-PSK and others.
If you create another mapping, you must correctly connect the branch metrics created outside the IP core to the input ports and correctly configure the polynomials GA and GB for the trellis generation.
For example, consider a received symbol that lands in sector number 2 with the following distances to the four nearest symbol map points:
Where the distance of the radius for 4 softbits is 1111. The distances are inverted to obtain the following branch metrics:
- Branch metric 0 = 0000
- Branch metric 1 = 0010
- Branch metric 2 = 0100
- Branch metric 3 = 1110
The decoder uses the coded bits (c1, c0) to select the branch metric number, which it uses to decide where to connect the branch metrics to the rr input of the Viterbi decoder. Branch metric 3 goes to the most significant bits (MSB) of rr; branch metric 0 goes to the least significant bits (LSB) of rr.
Tail-biting feeds the convolutional encoder with a block and terminates it with (L – 1) unknown bits taken from the end of the block. Tail-biting sets the initial state of the convolutional encoder with the last (L – 1) information bits. Tail-biting is decoded by replicating the block at the decoder or double feeding the block into the decoder. By decoding in the middle point, the trellis is forced into the state that is both the initial state and the end state. From the first decoding block, you can take the last half of the block; from the second decoded block (or second pass through the decoder), you can obtain the first half of the bits of the block.
Alternatively, if you initialize the convolutional encoder to zero, the initial state of the trellis is zero. The decoder knows the last (L – 1) bits to the convolutional encoder. They bring the convolutional encoder to a known end state. The decoder then uses this information to set the end state of the trellis with tr_init_state, which is derived from the last (L – 1) bits of the block in reverse order. For example, for a block that ends in: ...000101 If L = 5 and the decoder knows the last (L – 1) = 4 bits, it sets tr_init_state as 0101, which reversed and in binary is 1010, or 10 in decimal. The wizard generates tr_init_state as if it knows the last (L – 1) bits of each block.
However, the hybrid decoder allows you to set the initial state (usually zero) with bm_init_state. This signal ranges from 0 to 2 (L – 1) – 1, which are the trellis states. The bm_init_value signal initializes the state metric of the state indicated by bm_init_state. The decoder initializes all other states with zero. The appropriate value for this port is approximately 2(bmgwide – 2) or any value between 2(N + softbits) to 2(bmgwide – 1). Continuous decoders never reset the state metrics, which creates a possible difference if the same block of data is sent several times. Initially, the decoder sets the state metrics so that the state metric for state 0 is 0, and all others infinity. For any subsequent blocks, the state metrics contain whatever they have when the previous block ends.
|Viterbi architecure||Hybrid or Parallel||Selects the hybrid or parallel architecture.|
|BER||On or Off||Specifies the BER estimator option, refer to “BER Estimator” on page 3–7.|
|Node Sync||On or Off||Specifies the node synchronization option (only available when BER option is on).|
|Optimizations||None, Continuous, or Block||Specifies the optimization for the parallel decoder. if you select None you can turn on Best State Finder. However, to use less logic, turn off Best State Finder.|
In cases where the signal-to-noise ratio is sufficiently high to allow the decoder to decode an error-free output, the BER estimation is very close to the actual channel BER. When the decoder is not decoding an error-free output, the estimated BER is higher and more random than the actual channel BER, which introduces a degree of uncertainty directly proportional to the output errors.
The following equation represents node synchronization:
RR[i] = rr[((state_node_sync + i – 1) mod N) + 1]
where i is 1 to N.
RR and rr are treated as an array of width N of busses softbits wide. The range of valid values for state_node_sync is 0 to (N – 1).
|Number of Code Sets||1 to 8||The Viterbi IP core supports multiple code definitions. The multiple code set option allows up to eight code sets, where a code set comprises a code rate and associated generating polynomials.|
|Number of coded bits. (N)||
2 to 7 (hybrid)
2 to 4 (parallel)
|For every bit to be encoded, N bits are output. With the multiple code set option there are up to 5 different N parameters, which can be in any order. Valid only for Viterbi mode. For TCM mode only N = 2 is supported|
|Constraint length (L)||3 to 9||The constraint length. Defines the number of states in the convolutional encoder, where number of states = 2(L – 1). You can choose different values of L for each code set.|
|Decimal or Octal||–||Decimal or octal base representation for the generator polynomials. The design file representation is decimal, but you have the option of entering in either decimal or octal base.|
|Mode||V or T||Viterbi (V) or TCM mode (T).|
|GA, GB, GC, GD, GE, GF, GG||–||The generator polynomials. If you use the multiple code set option, the wizard enters a different set of polynomials in the respective gi group. The wizard provides default values that you can overwritte by any valid polynomial. (The wizard does not check whether the entered values are valid.) The parallel architecture uses only GA, GB, GC, and GD.|
For multiple code sets, the first code definition corresponds to the first line and is selected with sel_code input = 0; the second line is selected with sel_code = 1; the third with sel_code = 2 and so on. For each code definition you can select N, the polynomials, the constraint length L, and the mode (Viterbi or TCM). You can mix different constraint lengths with different TCM and Viterbi modes. The test data, which the wizardr creates, tests each of the code definitions. You can see these tests in the simulation with the testbench or if you look at the block_period_stim.txt file.
In hybrid mode, for constraint lengths of 3 and 4, the bitwidth of tr_init_state is 4, but the MegaCore function ignores the redundant higher bits.
For multiple constraint lengths, some of the last decoded bits may be incorrect, becauset of the Viterbi algorithm. To avoid this effect, give a lower BER, and reduce the probability of being on the wrong trellis path, set Optimization to None and turn on Best State Finder.
|Maximum constraint length (LMAX)||
5 to 9 (hybrid)
3 to 9 (parallel)
|The maximum constraint length LMAX. .|
|ACS Units (A)||1, 2, 4, 8, or 16||The number of ACS units, which adds a degree of parallelism (hybrid architecture only). The range of values available depends upon the value of maximum constraint length LMAX.|
|Traceback (v)||8 (minimum)||The traceback length, which is the number of stages in the trellis that are traced back to obtain a decoded bit. It is typically set to 6 × L for unpunctured codes, and up to 15 × L for highly punctured codes.|
|Softbits (softbits)||1 to 16||The number of soft decision bits per symbol. When softbits is set to 1 bit, the decoder acts as a hard decision decoder, and still allows for erased symbols to be entered using the eras_sym input.|
|Bmgwide||–||The precision of the state metric accumulation. The parameter editor selects and displays the optimum value, which depends on NMAX, LMAX and, softbits.|
The number of soft decision bits per symbol, softbits, represent 2 softbits – 1 soft 0s and 2 softbits – 1 soft 1s. The input values represent received signal amplitudes. If the input is in log-likelihood format, a transformation is required and you must use extra softbits to retain signal integrity. The decoder marks depunctured values separately. The decoder allows a hard-decision input when softbits = 1.
As the metrics grow, normalize them to avoid overflow. When a normalization occurs the decoder subtracts 2(bmgwide – 1) from all metrics and increases the normalization register by +1. The total metric value for the best path = (number of normalizations) × (2(bmgwide – 1)) + bestmet. The total metric value for the best path, the number of symbols processed, and the number of errors in the BER block indicate the quality of the channel and whether you have a suitable value for softbits. The output bestadd indicates the state that has the best metric.
The throughput calculator uses the following equation:
Hybrid throughput = fMAX/Z
- Z = 10, if log2C = 3
- Z= 2log2C, if log2C > 3
- log2C = L MAX – 2 – log2A
- LMAX is the maximum constraint length
- A is ACS units
- Parallel throughput = fMAX
Latency is the number of clock cycles it takes the decoder to process r the data and output it. Latency is from the first symbol to enter the IP core (sink_sop) up to the first symbol to leave (source_sop). The latency depends on the parameters. For the precise latency, perform simulation. The latency calculator uses the following formula for the hybrid architecture:
Number of clock cycles = Z × V
- V is the traceback length value that is in the input tb_length
- Z = 10, if log2C = 3
- Z = 2log2C, if log2C > 3
- log2C = L MAX – 2 – log2A, where A is ACS units
For the parallel architecture the number of clock cycles is approximately 4V.
|Number of bits per block||
The number of bits per block.
The number of bits per block × the number of blocks must be less than 50,000,000.
|Signal to noise ratio (dB)||The signal to noise ratio, which must be between 1 and 100.|
|Number of blocks||
The number of blocks.
The number of bits per block × the number of blocks must be less than 50,000,000.
|Pattern A||Enter the puncturing pattern A.|
|Pattern B||Enter the puncturing pattern B.|
All punctured codes are based on a mother code of rate 1/2. For external depuncturing you must depuncture the received data stream external to the decoder and input the data into the decoder n symbols at a time.
|Punctured Rate||Puncturing Scheme|
The ready latency on the Avalon-ST input interface is 1.
You may achieve a higher clock rate by driving the source ready signal source_rdy of the Viterbi high, and not connecting the sink ready signal sink_rdy.
The input interface is an Avalon-ST sink and the output interface is an Avalon-ST source. The Avalon-ST interface supports packet transfers with packets interleaved across multiple channels.
Avalon-ST interface signals can describe traditional streaming interfaces supporting a single stream of data without knowledge of channels or packet boundaries. Such interfaces typically contain data, ready, and valid signals. Avalon-ST interfaces can also support more complex protocols for burst and packet transfers with packets interleaved across multiple channels. The Avalon-ST interface inherently synchronizes multichannel designs, which allows you to achieve efficient, time-multiplexed implementations without having to implement complex control logic.
Avalon-ST interfaces support backpressure, which is a flow control mechanism where a sink can signal to a source to stop sending data. The sink typically uses backpressure to stop the flow of data when its FIFO buffers are full or when it has congestion on its output.
|clk||The main system clock. The whole MegaCore function operates on the rising edge of clk.|
|reset||Reset. The entire decoder is asynchronously reset when reset is asserted high. The reset signal resets the entire system. You must deassert the reset signal synchronously with respect to the rising edge of clk.|
|eras_sym[Nmax:1]||dat||Input||When asserted, eras_sym Indicates an erased symbol. Both rr and eras_sym are Avalon-ST dat inputs|
|rr||dat||Input||Data input, which takes in n symbols, each softbits wide per clock. In TCM mode the rr width is (2N × softbits:1); in Viterbi mode the rr width is (nmax × softbits:1).Both rr and eras_sym are Avalon-ST dat inputs|
|sink_eop||eop||Input||End of packet (block) signal. sink_eop delineates the packet boundaries on the rr bus. When sink_eop is high, the end of the packet is present on the dat bus. sink_eop is asserted on the last transfer of every packet. This signal applies to block decoding only.|
|sink_rdy||ready||Output||Data transfer enable signal.The interface sink drives sink_rdy and controls the flow of data across the interface. sink_rdy behaves as a read enable from sink to source. When the source observes sink_rdy asserted on the clk rising edge, it can drive the Avalon-ST data interface signals and assert sink_val as early as the next clock cycle, if data is available. In the hybrid architecture, sink_rdy is asserted for one clock cycle at a time. If data is not available at the time, you have to wait for the next sink_rdy pulse.|
|sink_sop||sop||Input||Start of packet (block) signal. sop delineates the packet boundaries on the rr bus. When sink_sop is high, the start of the packet is present on the rr bus. sink_sop is asserted on the first transfer of every packet This signal applies to block decoding only.|
|sink_val||val||Input||Data valid signal. sink_val indicates the validity of the data signals. sink_val is updated on every clock edge where sink_rdy is sampled asserted, and holds its current value along with the dat bus where sink_rdy is sampled deasserted. When sink_val is asserted, the Avalon-ST data interface signals are valid. When sink_val is deasserted, the Avalon-ST data interface signals are invalid and you must disregard them. To determine whether new data has been received, the sink qualifies the sink_val signal with the previous state of the sink_rdy signal.|
In Qsys systems, this Avalon-ST-compliant data bus includes all the Avalon-ST input data and configuration signals. The signals are in the following order from MSB to LSB:
|decbit||dat||Output||The decbit signal contains output bits when source_val is asserted.|
|source_eop||eop||Output||End of packet (block) signal. if you select continuous optimization, this signal is left open and you must remove it from the testbench.|
|source_rdy||ready||Input||Data transfer enable signal. The sink interface drives source_rdy and uses it to control the flow of data across the interface. ena behaves as a read enable from sink to source. When the source observes source_rdy asserted on the clk rising edge it drives, on the following clk rising edge, the Avalon-ST data interface signals and asserts source_val. The sink captures the data interface signals on the following clk rising edge. If the source is unable to provide new data, it deasserts source_val for one or more clock cycles until it is prepared to drive valid data interface signals.|
|source_sop||sop||Output||Start of packet (block) signal. if you select continuous optimization, this signal is left open and you must remove it from the testbench.|
|source_val||val||Output||Data valid signal. The IP core assers source_val high for one clock cycle, whenever there is a valid output on the decbit signal.|
In Qsys systems, this Avalon-ST-compliant data bus includes all the Avalon-ST output data and configuration signals. The signals are in the following order from MSB to LSB:
|ber_clear||Reset for the BER counter. Only for the BER block option.|
|bm_init_state[(L-1):1]||Specifies the state in which to initialize with the value from the bm_init_value bus. All other state metrics are set to zero. the IP core latches bm_init_state when sink_sop is asserted. Hybrid architecture only.|
Specifies the value of the metric that initializes the start state. All other metrics are set to 0. bm_init_value must be larger than (L × 2(softbits – 1)). the IP core latches bm_init_value when sink_sop is asserted. Hybrid architecture only.
|sel_code[log2(Ncodes):1]||Selects the codeword. ’0’ selects the first codeword, ‘1’ selects the second, and so on. The bus size increases according to the number of codes specified. The IP core latches sel_code when sink_sop is asserted.|
Specifies the node synchronization rotation to rr.
The IP core latches state_node_sync signal when sink_sop is asserted. Available only when you turn on Node Sync.
|tb_length||Traceback length. The maximum width of tb_length is equal to the maximum value of parameter v. The IP core latches tb_length input when sink_sop is asserted. This IP core disables this signal if you select the continuous optimization: you must then remove it from the testbench. Not available for parallel architectures with block optimization.|
|tb_type||Parallel architectures only. Altera recommends that you set tb_type high always for future compatibility. In block decoding when tb_type is low, the decoder starts from state 0; when tb_type is high, the decoder uses the state specified in tr_init_state[(L-1):1]. For block decoding set tb_type high. The IP core latches tb_type when sink_eop is asserted. If you select None or Continuous optimization, the IP core connects this input to zero.|
|tr_init_state[(L-1):1]||Specifies the state to start the traceback from, when tb_type is asserted high. The IP core latches tr_init_state when sink_eop is asserted. If you select continuous optimization, this input is removed from the top level design and connected to zero in the inner core.|
|bestadd[(L-1):1]||The best address state. The address corresponding to the best metric as it is being found by the best state finder. The metric of this state if shown in bestmet. If you select Continuous or None optimization and turn off best state finder, the IP core leaves this signal open. For parallel decoders, the IP core removes this signal.|
|bestmet[bmgwide:1]||The best metric. The bestmet signal shows the best state metric for every trellis step as the best state finder finds it. The state that contains this best metric is shown in bestadd. If you select Continuous or None for optimization and turn off best state finder, the IP core leave this signal open, For parallel decoders, the IP core removes this signal.|
|normalizations[8:1]||The normalizations bus indicates in real time the number of normalizations that occur since you activated sink_sop.|
|numerr||The numerr bus contains the number of errors detected during a block. The iP core updates it each time it detects an error, so you can see the location of individual errors. It is reset when source_sop asserted; it is valid two-clock cycles after source_sop. The wizard automatically sets the width of this bus. If you do not select a BER block, the IP cores leaves this signal open. Only available when you select the BER estimator option|
|IP Core Version||User Guide|
|15.0||Viterbi IP Core User Guide v15.0|
|14.1||Viterbi IP Core User Guide v14.1|
|August 2014||14.0 Arria 10 Edition||
|November 2012||12.1||Added support for Arria V GZ devices.|
|July 2010||10.0||Added preliminary support for Stratix V devices.|