galileo/docs/navigation_hardware_software_partition.md

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

One record is emitted 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	Decoder validity gate
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.

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.