Introduction
The Narrowband Ultra-High Frequency Follow-On (UFO) SATCOM Interference Cancellation (NUSIC) IP core was developed to address interference in legacy UFO military communications channels (using shaped or unshaped BPSK modulation schemes). The module is capable of mitigating both uplinked and downlinked interference (i.e., introduced before or after the satellite transponder). Due to the hard limiting effects of the transponder, uplink and downlink interference must be handled differently. The NUSIC core contains a detector to determine both the presence of an interferer, as well as whether it is uplink or downlink interference. The module is capable of mitigating uplinked stationary and sweeping continuous wave (CW) interferers with up to +10 dB J/S and FM voice interferers up to +7dB J/S. Performance on downlinked interference is better still, up to +20 dB J/S on stationary and swept CW, and +10 dB J/S with an FM voice interference. Additional performance specifications will be made available upon request.
Along with initialization and setup parameters (symbol rate, modulation type, etc.), the NUSIC module will receive complex baseband data at 4 times the symbol rate. The unit will mitigate any interference and output the filtered signal at 4 times the symbol rate.
Additional architectures are also available from GIRD Systems providing other signal of interest (SOI) modulations (e.g., shaped offset QPSK and multi-h CPM).
Features
- Uplink and downlink interference mitigation in a hard limited UFO SATCOM channel
- Fixed-point data interface
- Supports streaming processing (continuous data feed)
- Utilizes FPGA architecture features (multiplier/DSP blocks, Block RAM, etc.) via inference
- Bit-accurate MATLAB model and testbench
- VHDL testbench
Interface Description
The component interface is shown in Figure 1.
Figure 1: NUSIC Core Top-Level Interface
Inputs
The signal inputs to the NUSIC core are defined in Table 1.
Table 1: NUSIC Core Input Signals
Input Name / Type / DescriptionCLOCK / std_logic / Core processing clock
RESET / std_logic / Active high, synchronous reset
RCV_IN / std_logic_vector(2*PARAMS.rdata_width – 1:0) / Complex input signal
MSBs: Quadrature
LSBs: In-Phase
DVALIDI / std_logic / Specifies incoming RCV_IN data is valid
ALGO_CONFIG / config_t (see Configuration section) / Algorithm configuration information record
Outputs
The signal outputs from the NUSIC core are defined in Table 2.
Table 2: FFT/IFFT Core Output Signals
Output Name / Type / DescriptionRCV_OUT / std_logic_vector(2*PARAMS.rdata_width – 1:0) / Complex output signal
MSBs: Quadrature
LSBs: In-Phase
DVALIDO / std_logic / Qualifies data on RCV_OUT bus
Configuration
The NUSIC component is configured via the ALGO_CONFIG input record providing the channel configuration information including selection of baud rate and mode. The config_t record is specified as follows:
type config_t is record
bypass : unsigned(15 downto 14);
reserved_us : unsigned(13 downto 10);
subband : unsigned(9 downto 8);
fd_index : unsigned(7 downto 4);
mode : unsigned(3 downto 2);
bw : unsigned(1 downto 0);
end record config_t;
The bypass, reserved_us, subband, and bwentries should be set to “0”. The valid mode settings are “00” for Shaped BPSK and “11” for Unshaped BPSK. Table 3 provides the available fd_index settings for Shaped BPSK and Table 4 provides the available fd_index settings for Unshaped BPSK.
Table 3: FD Index to Data Rate Mapping for Shaped BPSK Mode (Mode=0)
FD Index / Data Rate0 / 1,200
1 / 2,400
2 / N/A
3 / 9,600
4 / 19,200
Table 4: FD Index to Data Rate Mapping for Unshaped BPSK Mode (Mode=3)
FD Index / Data Rate0 / 9,600
1 / 19,200
Timing Diagram
An overall sample timing diagram for the NUSIC is shown in Error! Reference source not found.. The algorithm is currently designed to operate with a 200 MHz CLOCK signal to ensure that all operations can be completed in the sample time required; however, a slower clock may be possible if not supporting all modes. The RCV_IN samples are expected to be provided at 4 times the sample rate of the currently configured mode with a DVALIDI pulse validating the sample. For example, the BPSK modes all require the same sample rate of 76,800 bps, which requires a sample to be provided every 2604 1/6 clock cycles. This can be accomplished by incorporating a fractional resampler to provide the 2604 1/6 nominal rate. The samples should occur regularly in time (i.e., equal number of clocks between data samples) to allow the internal algorithm processing to complete for each sample. In other words, the fractional resampler output should be metered to provide a sample about every 2604 clock cycles.
The ALGO_CONFIG data must be applied prior to the first input sample and must remain static for the entirety of processing. If the ALGO_CONFIG data changes, the RESET signal must be pulsed to reset the algorithm and apply the new ALGO_CONFIG parameters. The new parameters will be applied to the next RCV_IN data input to the algorithm.
After applying the first RCV_IN data and subsequent samples at 4x the current mode’s sample rate, the resulting RCV_OUT data will be available 1500 samples(1500 * 2604 clock cycles) later at the same rate.
Table 5: Timing Diagram for Algorithm Input
IPC1000 | October 2014Data Sheet / / Page | 1
/ Narrowband UFO SATCOM Interference Cancellation Module v1.0
File List
Table 6lists theVHDL source files included with the project. Source files are also included for fixed-point MATLAB models as listed in Table 7. Additionally, testbenches for VHDL and fixed-point MATLAB models are included as listed in Table 8 and Table 9.
Table 6: NUSIC Core VHDL Source File List
File Name / DescriptionTable 7 : NUSIC Core MATLAB Model Source File List
File Name / DescriptionTable 8: NUSIC Core VHDL Testbench Files
File Name / Descriptionnusic_tb.vhd / Testbench associated with top level VHDL source
run_tb.do / Modelsim-compatible script to compile source and testbench
testbench_pkg.vhd / Package file for testbench convenience functions
textio_pkg.vhd / Package file for text input/output; overloads/extends std.textio
Table 9: NUSICCore MATLAB Testbench Files
File Name / Descriptionnusic_tb.m / Testbench associated with top level MATLAB model
Functional Description
The NUSIC IP module implements a proprietary interference mitigation algorithm on UFO SATCOM channels. The module operates on complex baseband data and requires knowledge of the modulation type and symbol rate of the signal of interest (SOI). Although there are many published interference mitigation techniques that have found wide use and success in practice, none are suitable for resolving uplinked interference in a UFO SATCOM channel. The hard limiting characteristic of the satellite transponders has an extremely detrimental effect on typical interference mitigation algorithms because much of the SOI information is lost. Even if the original interference could be removed perfectly from the hard limiter output, the remaining signal would still contain significant distortion, making it highly unlikely that a demodulator could successfully retrieve the SOI information.
It is well understood that the transponder hard limiter clips incoming signals, resulting in an output resembling a square wave (although with somewhat rounded corners). A bandpass filter follows the hard limiter to suppress any out of band spectral regrowth. If the input signal is constant envelope, the bandpass filter restores the signal perfectly since no intermodulation products would be produced due to harmonics being out of band. Such is the case for normal UFO SATCOM signals since they are very careful to maintain a constant envelope.
Unfortunately, when interference is present, the resulting signal (SOI + Interference) is no longer constant envelope, causing distortion. To further understand, we examine the scenario at baseband, shown in Figure 5. Although there are additional effects caused by the bandpass filtering, the snapshot depicted in Figure 5 is a fairly accurate representation. At any moment in time, the signal entering the hard limiter is the vector sum of the strong interferer plus the SOI constellation. Thus, the different symbols of the SOI only constitute a small phase change of the hard limited signal, effectively compressing the SOI constellation to a small arc around the interference. It is also important to note that, in general, the interference phase will not be stationary, but moving around the circle in unpredictable patterns, carrying the compressed SOI constellation along with it. Further, when the phase of the interference lines up with the phase of the constellation (or either axis of the QPSK constellation), two symbols line up with each other and data is completely lost (right side of Figure 5).
GIRD Systems has developed a unique algorithm to estimate the underlying SOI in the presence of interference in a hard limited channel. Further, the algorithm has additional modes which are used when the interference is determined to be downlink (i.e., not hard limited). The NUSIC module contains circuitry to seamlessly switch between modes depending on the type of interference encountered.
Resource Utilization
The default configuration of the core was used to generate resource utilization estimates. This includes a single-channel, 16-bit I/Q data path and support for shaped and unshaped BPSK for local and uplink interferers. Alternative configurations are available providing support for QPSK and CPM modes as well as multichannel configurations in addition to custom implementations tailored to specific resource constraints. Please contact GIRD Systems for details.
The NUSIC IP Core is written almost entirely as hardware-agnostic VHDL; however, certain components are currently targeted to a Xilinx-specific implementation and would require additional effort to remove those dependencies. Contact GIRD Systems if you are targeting an alternative platform. Resource estimates for a Xilinx Virtex 7 part are provided inTable 10. Vivado 2014.1 was used to generate the resource estimates. Vivado includes several synthesis and implementation options that will impact resource utilization and maximum achievable circuit frequency (Fmax). The estimates reported in this document use the default values provided by the vendor for all synthesis and implementation options. The user can adjust vendor-specific settings to impact the performance/resource utilization tradeoff for their application. Contact GIRD Systems for assistance in tuning build parameters and constraints for specific application needs. Note that several other factors may cause variation in resource utilization and circuit performance estimates, such as overall device utilization, routing congestion, place-and-route/fitter seed, etc.
Table 10: Xilinx Device Utilization Estimates
Device / Logic / Block RAMs / MultipliersSlice LUTs / Slice Registers / RAMB36s / RAMB18s / DSP48E1s
Virtex 7 XC7VX485T -1 / 39,463 / 38,333 / 28 / 44 / 209
Simulation
The NUSIC IP Coreis delivered with a VHDL testbench as well as a fixed-point MATLAB model and associated testbench. The MATLAB and VHDL testbenches are setup to read data from the same text file and produce matching results.
Most VHDL simulators should be capable of simulating the NUSIC IP core. During development and testing of the core, ModelSim DE 10.1d and MATLAB 2009a were used for simulation. No additional external libraries or toolboxes are required. There are 2 provided testbenches: a fixed-point VHDL testbench, and a bit-accurate fixed-point MATLAB testbench. The VHDL testbench depends on stimulus data generated by the MATLAB fixed-point testbench. Thus, the MATLAB fixed-point testbench must be run prior to running the VHDL testbench.
For the fixed-point MATLAB testbench, several simulation and core parameters must be set to configure the test. The parameters include settings associated with the stimulus data being generated including properties of the data itself as well as properties for the interference type selected. Table 11 provides a list of the configurable parameters for the generation of the signal of interest as well as the interferer for input to the models.
Table 11: Parameters for SATCOM Data Generation
Parameter / DescriptioneBW / Excess bandwidth of generated SOI (>1 will use rectangular pulses)
numbits / Number of bits to generate
SNR / Signal to noise ratio of the generated SATCOM data
INT_F / Frequency offset of the interferer
INT_power / Power (in dB) of the interferer
INT_TYPES / Interference type (1=CW, 2=BPSK, 3=QPSK, 4=Band-pass Filtered AWGN, 5=FM)
INT_BWS / Bandwidth of the interference signal
FM_rate / FM sweep rate for swept interferer
In the VHDL testbench, there are several simulation and core configuration parameters that have corresponding parameters in the MATLAB fixed-point testbench. To achieve a bit-true comparison with the MATLAB model, these parameters must have the same values as the corresponding MATLAB testbench parameters. Table 12 lists the relevant MATLAB and corresponding VHDL simulation parameters. A ModelSim-compatible DO script is also included to compile the VHDL source and testbench.
Table 12 : Simulation Parameters
MATLAB Parameter / VHDL Parameter / Descriptionconfig.mode / CONFIG.mode / Signal of interest type (see Configuration section)
config.fd_index / CONFIG.fd_index / Index into the data rate table for the selected mode (see Configuration section)
IPC1000 | October 2014
Data Sheet / / Page | 1