3.3 KiB
Navigation hardware/software partition
The measured partition keeps sample-rate work in the tracking IP and performs I/NAV decoding in software. No result in this milestone justifies placing a soft-decision Viterbi decoder or navigation database in RTL.
Tracking-IP output contract
The tracking IP uses E1C VE/E/P/L/VL for shared carrier/code loops, C/N0, and BOC-aware lock monitoring. A separate E1B correlator branch consumes the same sample-by-sample NCO phases. One navigation record is emitted from that branch for every 4 ms E1B primary-code epoch:
| Field | Proposed representation | Meaning |
|---|---|---|
| PRN/channel | unsigned integer | Logical satellite and component |
| start/end timestamp | 64-bit sample counters | Continuous receiver time association |
| Prompt I/Q | signed fixed-point accumulators | Unreduced coherent evidence |
| carrier phase/frequency | NCO state/measurement words | Reprocessing and phase diagnostics |
| code phase | unsigned fixed-point chips | Code-time association |
| C/N0 | fixed-point dB-Hz or invalid | Monitoring only |
| carrier/code lock | bits | E1C pilot-derived decoder validity gate |
| lock metric valid | bit | BOC smoothing/calibration window is valid |
| BOC main/side metrics | fixed-point monitor words | false-lock diagnosis |
| cycle slip/discontinuity | bits | Immediate symbol/page synchronizer reset |
| valid | bit | Transaction validity |
The interface should use an AXI-Stream-like valid/ready transaction. A FIFO
must absorb software service latency; backpressure cannot be allowed to stop the
sample-rate tracking datapath. At 250 records/s/channel, even 36 active E1B
channels produce only 9000 records/s, so a memory-mapped DMA ring is sufficient.
E1C secondary-code synchronization can remain software-assisted initially: a bounded Prompt buffer is searched for secondary phase and residual carrier frequency, then the phase is written to tracking-channel state. Continuous secondary wipeoff and the E1C/E1B correlator branches remain sample-rate RTL.
Software decoder
Software retains floating numpy.float64 prompt/soft values in the reference
model and performs:
prompt axis and symbol synchronization
-> page synchronization and polarity resolution
-> 30x8 deinterleaving
-> soft Viterbi decode
-> vertical-page assembly and CRC-24Q
-> typed word parsing
-> atomic IODnav ephemeris assembly
-> GST/clock/health navigation database
This split keeps policy-rich, low-rate state machines inspectable and updateable.
The saved prompt_epochs.npz files are the exact boundary between future RTL
tracking and the software decoder. HDL verification shall replay the same RF
vector, compare each tracking epoch with the bit-true model, then feed the RTL
prompt records into this decoder without SignalSim truth.
Conditions that could justify later hardware offload
Only measured CPU load, power, or startup-latency failure should trigger an offload study. Plausible granular offloads are symbol accumulate-and-dump, deinterleaver address generation, or a shared Viterbi accelerator. CRC, word parsing, ephemeris consistency, time rollover handling, and the navigation store remain better software candidates because their throughput is negligible and their standards/policy behavior is state-rich.