# 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: ```text 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.