Abbreviations & Symbol Index

This is the fast-lookup index for every acronym, opcode-mnemonic prefix, register name, firmware idiom, runtime symbol family, CSR/address block, and collective term that recurs across the wiki. It complements the Master Glossary: the glossary defines (a crisp paragraph + canonical anchor + deep page per term); this index cross-references (a one-line expansion + a link to the page that owns the term), and it adds the symbol-prefix families the glossary does not enumerate (nrt_*, nrtucode_*, aws_hal_q7_*, kmgr_*, tdrv_*, enc_*, ivp_*, module__xdref_*).

How to use it. Land here when you hit a bare token in another page — cc_op, tdrv_ctx, ivp_, P%i:, NQ, EVT_SEM — and want "what is it, and where is it defined". Find the row, read the one-line expansion, click the defining page. For the full definition + anchor, follow the glossary link in the row (or the Master Glossary directly). For the byte-level encoding lookup, see the Master ISA Encoding Appendix.

Provenance. Every expansion is derived from static analysis of the shipped binaries — recovered symbols, embedded prototype strings, config tokens, opcode-name string pools, and device .rodata literals. Symbol-family counts are reproducible: an nm/strings/rg against the one named binary by absolute path reproduces them. Where a row's meaning is inferred rather than read, it carries a confidence tag ([OBSERVED] / [INFERRED] / [MED]); most are [HIGH/OBSERVED] from symbols and are tagged only where confusable. The five NOTE / GOTCHA callouts at the end disambiguate the genuinely-confusable abbreviations (the v5-label overload, SP vs TOP_SP, ct37 vs arch_id 36, XRP the not-Cadence-framework, CCE the not-an-engine).

Literal | inside a cell is escaped \|. A row that points at the glossary means the term is defined there; a row that points at a subsystem page means that page owns the deep treatment.

1. Engine & codename abbreviations

The generation codenames, the coretype/arch_id identity bytes, and the engine ordinals. Deep table: Codename ↔ Generation Cross-Walk and the Codename Cross-Walk Table.

2. ISA mnemonic families & opcode prefixes

The Vision-Q7 mnemonic family, the scalar base, and the recurring opcode bytes. Byte-level encodings: Master ISA Encoding Appendix.

3. FLIX encoding terms

The Tensilica VLIW scheme. Deep decoder: FLIX Bundle-Decoding Methodology; byte tables: FLIX Encoding.

4. Register-file names & ISA metadata fields

The eight register files (two scalar, six Vision-Q7 SIMD) and the per-operand metadata tables. Deep page: The Eight Register Files.

5. Firmware & device symbol idioms

The device-firmware build idioms used as recovery anchors. The trace tags are confirmed in the device .rodata of libnrtucode_internal.so (S: literals 16×, P%i: literals 1016×).

6. Runtime / host symbol families

The host x86-64 runtime prefixes. Counts are reproducible with nm/strings against the one named binary; the host families (aws_hal_*, kmgr_*, tdrv_*, enc_*) live in libnrt.so as embedded prototype strings (the library is not stripped — these are its symbolized C++ prototypes). nrtucode_* is a real .symtab family in libnrtucode_internal.so.

7. CSR & address-block names

The device control/status-register block names and SoC address regions. Block-name index: CSR Field-Table Index.

8. Collective & NCFW vocabulary

The collective-communication control plane: the program the NCFW/TOP_SP walks, the host-side encoder family, the messaging transport, and the DMA datapaths.

9. Container, compiler & general acronyms

10. Disambiguation callouts — the confusable abbreviations

GOTCHA — the "v5" label is overloaded three ways; none derives the other. CoreV5 / core_v5 is the compiler ArchLevel slot (host platform / libwalrus), and it maps to MARIANA_PLUS / Trn3-PRE — coretype 29 / arch_id 0x1c, an NCFW-present gen. NC-v5 / GPSIMD coretype 37 is the genuine 5th silicon — MAVERICK — with no NCFW image. NeuronCoreVersion::V5 = 5 is the arch-ISA cap enum (present in maverick, absent in mariana). A page citing "v5" must say which axis. See Codename Cross-Walk §CoreV5-vs-NC-v5 and MAVERICK Profile §1.

GOTCHA — SP vs TOP_SP are two distinct engines. SP (TPB_SP) is the per-NeuronCore Sync/control front-end executor (engine_idx 4); TOP_SP is the standalone NX-core sequencer that walks the cc_op collective program in SPAD (engine_idx 5). They share the _SP suffix and the TPB_SP token but are not the same core. See TOP_SP Lowering.

NOTE — ct37 is OBSERVED, arch_id 36 is INFERRED. MAVERICK's coretype 37 is anchored twice in firmware (the header enum ordinal and the twin resolver bitmasks) → [HIGH/OBSERVED]. Its arch_id = 36 (0x24) has no cmp $0x24 anywhere and no v5 NCFW image — it is the coretype − 1 extrapolation only → [MED/INFERRED]. Never hard-code arch_id 36. See Codename Cross-Walk.

NOTE — XRP is not a Cadence framework here. Despite the name there is no Cadence XRP present in the corpus; the host↔DSP transport is a bespoke Annapurna-Labs message queue. The only xrp substring corpus-wide is libnrt's unrelated AF_RXRPC. See XRP Host↔DSP Messaging.

NOTE — CCE is a datapath, not an engine, and NCFW is a core, not the FLIX one. CCE (Compute-DMA) is the in-transfer reduce path inside the SDMA fabric — there is no "CCE engine". NCFW is a separate scalar Xtensa-LX management core: do not run the FLIX decoder on its images (the spurious "~26–28% FLIX" artifact comes from doing exactly that). Three cores, three ISAs: Q7 (Vision-Q7 FLIX, this wiki), NCFW (scalar-LX), TOP_SP (NX sequencer). See Keystone Facts and The NCFW Scalar-LX Core.

See also

• Master Glossary — the definitional reference (this index complements it).
• Master ISA Encoding Appendix — the byte-level opcode-encoding lookup.
• Codename ↔ Generation Cross-Walk + Cross-Walk Table — the codename ↔ coretype ↔ arch_id map.
• CSR Field-Table Index — the CSR-block-name index.
• Device-Firmware Globals · Exec-State Census · Host-Runtime Layouts — the struct censuses behind the symbol families.
• The Confidence & Walls Model — the tag and wall taxonomy.