GPS HDL Reference Applications Overview Not Working

I am working with the GPS HDL reference example from MathWorks:

GPS HDL Reference Applications Overview - MATLAB & Simulink

I am implementing this design on ZCU48DR hardware with the following configuration:

• RFDC configured for 4 samples per stream and 5× decimation
• Input sample rate: 3922.168 MSPS
• After additional decimation, the signal enters the acquisition and tracking IP GPS HDL Acquisition and Tracking Using C/A Code - MATLAB & Simulink at 32.768 MHz
• The clock provided to the IP is 196.608 MHz
• GPS HDL Acquisition and Tracking Using C/A Code - MATLAB & Simulink, and GPS HDL Data Decode and Position Estimation - MATLAB & Simulink are integrated into a single IP, similar to the reference design
• I have also verified the 1 kHz navigation data rate on hardware

Issue:

• The acquisition stage works correctly (satellites are detected and tracking is stable)
• However, in the decoding stage, frame synchronization fails
• This suggests that the LNAV data is not valid

To further debug, I generated an 8-second LNAV signal from the acquisition and tracking HDL model in simulation, but the decoder still fails to decode that LNAV signal.

Questions:

1. Has this GPS HDL reference example been validated on hardware (particularly ZCU48DR or RFSoC platforms)?
2. What could cause frame synchronization failure even when acquisition and tracking appear correct?
3. Could there be an issue with bit alignment, timing, or scaling between tracking output and decoder input?
4. Is there any recommended method to verify LNAV integrity before decoding?

Any guidance on where to debug this issue would be greatly appreciated.

[Mohsin]

Hi, if you have any question or suggestion, I'm open for discussion

[Karthik Akula]

did you get a chance to verify until position estimation in simulation?

Is the partitioning b/w HW SW taken care of?

Is the data decoding part is modified to operate at the 196.608 MHz in Simulink?

How is "1KHz" navigation data rate verified?

I think the waveform generation in acquisition and tracking is not sophisticated enough for the entire chain. it's meant for only acquisition and tracking.

Are you using the workflow defined in https://www.mathworks.com/help/soc/ug/gps-acquisition-using-rfsoc-device.html?

Are you modifying this example to include data decoding or is it a completely newer one?

[Mohsin]

Hi Karthik,

Thank you for the response.

1. I have verified the chain up to position estimation in simulation using the provided MATLAB workflow, and the simulation behaves as expected.
2. Yes, HW/SW partitioning has been taken care of. The Acquisition & Tracking and Data Decode portions are implemented in HDL, while the remaining processing is handled separately.
3. The Data Decode portion itself was not structurally modified to operate at 196.608 MHz. The decoder is clocked at 196.608 MHz in hardware, while the navigation data input rate to the decoder is maintained at 1 kHz through the valid signal interface from the tracking stage.
4. The 1 kHz navigation data rate was verified in hardware by monitoring the valid signal from the tracking stage using ILA and counting the pulse interval relative to the system clock.
5. Regarding waveform generation, I also suspect this may be related. I used the waveform generated from the Acquisition & Tracking HDL workflow and fed the resulting LNAV-related outputs into the decoder, but frame synchronization still did not occur.
6. Yes, I am using just the data path of the RFSoC workflow described here:GPS Acquisition Using RFSoC Device
7. I modified this workflow to additionally integrate the Data Decode stage from the GPS HDL Data Decode and Position Estimation example into the same design. It is not a completely new receiver architecture.
8. also the operation is performed on the real time recoreded data of gps not with the generator

At the moment, the main issue is that acquisition/tracking appears stable, but the decoder never achieves frame synchronization or asserts wordValid.

Please let me know if there are any recommended checks for validating the LNAV symbols before the decoder stage.

Thank you.