olo_fix_cordic_rot¶
Status Information¶
VHDL Source: olo_fix_cordic_rot
Bit-true Model: olo_fix_cordic_rot
Description¶
Overview¶
This entity implements the rotating CORDIC algorithm. This algorithm is usually used to convert from the polar to the cartesian coordinate system, i.e. to calculate I and Q components (complex numbers) from an angle and a magnitude.
The algorithm can be implemented in two different modes:
- SERIAL
- Iterations are executed one after the other
- A new sample can be accepted every Iterations_g clock cycles.
- Lowest possible resource usage
- PIPELINED
- Iterations are implemented in individual pipeline stages
- Every clock cycle a new sample can be accepted
- Highest possible throughput
For details about the fixed-point number format used in Open Logic, refer to the fixed point principles.
Gain Compensation¶
The CORDIC algorithm has an inherent gain that depends on the number of iterations. This gain can optionally be compensated directly within the olo_fix_cordic_rot entity. The internal gain compensation works most efficiently if the internal format IntXyFmt_g fits into one multiplier of the target device.
Alternatively, the user may choose to do the gain compensation outside of the entity, e.g. by using an olo_fix_mult entity before the CORDIC to scale down the input magnitude. For this the gain factor must be known, hence the formula is given below:
Note that depending on the application the gain compensation may be omitted completely. Therefore it is optional and can be controlled through the generic GainCorrCoefFmt_g.
Latency¶
The latency of the entity depends on several factors and can best be determined in the simulation.
Note: Latency is not guaranteed to be constant across different versions. It's therefore best to design user logic to be independent of the latency of this block (e.g. through olo_base_latency_comp).
In the current version the latency can be calculated as follows:
- Mode_g = "PIPELINED" with gain correction: Latency = 4 + Iterations_g + resize_latency
- Mode_g = "PIPELINED" without gain correction (GainCorrCoefFmt_g = "NONE"): Latency = 3 + Iterations_g + resize_latency
- Mode_g = "SERIAL" with gain correction: Latency = 4 + Iterations_g + resize_latency
- Mode_g = "SERIAL" without gain correction (GainCorrCoefFmt_g = "NONE"): Latency = 3 + Iterations_g + resize_latency
Where resize_latency is calculated as follows:
- +1 cycle if Round_g is NOT "Trunc_s"
- +1 cycle if Saturate_g is NOT "None_s"
Generics¶
| Name | Type | Default | Description |
|---|---|---|---|
| InMagFmt_g | string | - | Input magnitude format Must be (0,x,y) String representation of an en_cl_fix Format_t (e.g. "(0,1,15)") |
| InAngFmt_g | string | - | Input angle format Must be (0,0,x) String representation of an en_cl_fix Format_t (e.g. "(0,0,15)") |
| OutFmt_g | string | - | Output data format Usually (1,x,y) String representation of an en_cl_fix Format_t (e.g. "(1,1,15)") |
| IntXyFmt_g | string | "AUTO" | Internal format for X/Y values. With "AUTO" the format is chosen automatically. For manual control, specify a string representation of a signed en_cl_fix Format_t (e.g. "(1,1,15)"). Refer to Format Considerations for details |
| IntAngFmt_g | string | "AUTO" | Internal format for angles With "AUTO" the format is chosen automatically. For manual control, specify a string representation of a (1,-2,x) en_cl_fix Format_t (e.g. "(1,-2,15)"). Refer to Format Considerations for details |
| Iterations_g | positive | 16 | Number of CORDIC iterations. Range: 3 .. 32 Refer to Format Considerations for details |
| Mode_g | string | "PIPELINED" | CORDIC operation mode "SERIAL": one iteration per clock cycle "PIPELINED": Pipelined mode (one sample per clock cycle) |
| GainCorrCoefFmt_g | string | "(0,0,17)" | Format of the gain correction coefficient, specify a string representation of a signed en_cl_fix Format_t (e.g. "(0,0,15)"). Refer to Format Considerations. To disable the internal gain compensation, choose "NONE" |
| Round_g | string | "Trunc_s" | Rounding mode String representation of an en_cl_fix FixRound_t. |
| Saturate_g | string | "Warn_s" | Saturation mode String representation of an en_cl_fix FixSaturate_t. |
Interfaces¶
Control¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| Clk | in | 1 | - | Clock |
| Rst | in | 1 | - | Reset input (high-active, synchronous to Clk) |
Input Data¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| In_Mag | in | width(InMagFmt_g) | N/A | Input magnitude Format InMagFmt_g |
| In_Ang | in | width(InAngFmt_g) | N/A | Input angle, Normalized units (1.0 = 360° = 2*PI) Format InAngFmt_g |
| In_Valid | in | 1 | '1' | AXI4-Stream handshaking signal for In_Mag and In_Ang |
| In_Ready | out | 1 | N/A | AXI4-Stream ready signal for In_Mag and In_Ang Used in "SERIAL" mode to signal when a new input sample is taken |
Output Data¶
| Name | In/Out | Length | Default | Description |
|---|---|---|---|---|
| Out_I | out | width(OutFmt_g) | - | In-phase/real part of output data Format: OutFmt_g |
| Out_Q | out | width(OutFmt_g) | - | Quadrature/imaginary part of output data Format: OutFmt_g |
| Out_Valid | out | 1 | N/A | AXI4-Stream handshaking signal for Out_Q and Out_I |
Note The output interface does not implement backpressure (Ready). If backpressure is required, the user ideally implements it over the whole processing chain using olo_base_flowctrl_handler.
Detail¶
Format Considerations¶
IntXyFmt_g¶
The format for internal calculation of X and Y components must be signed.
The more fractional bits are used, the more precise the calculation gets. Usually a few more fractional bits than in OutFmt_g are required.
The number of integer bits must be chosen to ensure that no overflows happen during calculation. Except for special cases one more bit than for InMagFmt_g is required.
Optimization is best performed based on the bit-true python model.
For "AUTO" mode, the internal format is chosen as follows:
- Sign bit: yes
- Integer bits: InMagFmt_g.I + 1
- Fractional bits: OutFmt_g.F + 3
GainCorrCoefFmt_g¶
For optimal absolute precision, the gain correction coefficient shall have at least the same number of fractional bits as OutFmt_g.
In many cases the absolute precision is secondary and only the relative precision matters. In such cases the number of bits can be reduced to save resources. Because all samples receive the same gain correction, any errors in the correction factor will not impact the relative precision between samples.
IntAngFmt_g¶
Internal calculation format for angles (must be signed) and have -2 integer bits (because only one quadrant is used, angles 0...0.25).)
The more fractional bits, the more precise the calculation gets. Usually a few more bits than in InAngFmt_g are required.
Optimization is best performed based on the bit-true python model.
For "AUTO" mode, the internal format is chosen as follows:
- Sign bit: yes
- Integer bits: -2
- Fractional bits: InAngFmt_g.F + 3
Iterations_g¶
More iterations lead to more precise results. A good starting point is one iteration per bit in the output format.
Optimization is best performed based on the bit-true python model.