feat: DSS HWA driver implementation and host unit tests #111

New issue

Closed

opened 2026-07-23 18:56:27 +00:00 by hoogv · 0 comments

hoogv commented

2026-07-23 18:56:27 +00:00

Owner

Description

Adds hal/dss/hwa/hal_dss_hwa.c/.h — the DSS-side counterpart of the already-landed MSS HWA driver (#95/#96). Same physical Hardware Accelerator, dual-mapped at DSS-visible addresses (DSS_HWA1/DSS_HWA1_PARAM) instead of MSS's. Named hal_dss_hwa_*() rather than hal_hwa_*() to avoid collision should both ever be linked into the same firmware image.

Provides hal_dss_hwa_init() (TI mmWave SDK hwa.c-sourced bring-up sequence: disable, pulse ACCRESET, ungate clock, clear stale PARAMDONESTAT, zero all 16 param-RAM entries), hal_dss_hwa_load_param_set() (raw 32-byte param-set blob write — deliberately not a structured-field API, same rationale as the MSS driver), hal_dss_hwa_trigger() (single contiguous PARAMSTART..PARAMSTOP range, NLOOPS = 0), and hal_dss_hwa_is_done() (poll-only HWACCREG4.PARAMDONESTAT, no ISR path — DSS-local PARAM_DONE interrupts exist but are out of scope here, matching the MSS driver's polling-only shape).

Carries forward the same documented scope limits as the MSS driver: no real FFT/CFAR/log-magnitude/compression correctness validation (TRM defers to a separate Radar HWA User's Guide not available in this project), no individual PARAMn_x field API, no DMA-triggered param-sets or looped execution.

Use Case / Rationale

As a firmware developer, I need minimal DSS-side HWA bring-up/trigger/poll parity with the already-landed MSS driver, for firmware that runs signal-processing chains from the DSS core.

Acceptance Criteria

hal/dss/hwa/hal_dss_hwa.c/.h implemented against this project's current hal/registers/component/hwa.h/instance/hwa.h
testing/dss/hwa/test_dss_hwa.c passes under ctest
Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting

Functional Impact

None — self-contained addition alongside the already-landed Mailbox/EDMA/VIM/DSS-ADCBUF/DSS-INTC/DSS-Cache drivers.

Regulatory Impact

None

QMS Impact

None

Risk Impact

No new risk — same documented scope limits as the already-landed MSS HWA driver (no signal-processing correctness claims beyond what TI's CSL headers and reference bring-up sequence support). Existing risk coverage sufficient.

Relates to #4, relates to #99, relates to #101, relates to #103, relates to #105, relates to #107, relates to #109

### Description Adds `hal/dss/hwa/hal_dss_hwa.c`/`.h` — the DSS-side counterpart of the already-landed MSS HWA driver (#95/#96). Same physical Hardware Accelerator, dual-mapped at DSS-visible addresses (`DSS_HWA1`/`DSS_HWA1_PARAM`) instead of MSS's. Named `hal_dss_hwa_*()` rather than `hal_hwa_*()` to avoid collision should both ever be linked into the same firmware image. Provides `hal_dss_hwa_init()` (TI mmWave SDK `hwa.c`-sourced bring-up sequence: disable, pulse `ACCRESET`, ungate clock, clear stale `PARAMDONESTAT`, zero all 16 param-RAM entries), `hal_dss_hwa_load_param_set()` (raw 32-byte param-set blob write — deliberately not a structured-field API, same rationale as the MSS driver), `hal_dss_hwa_trigger()` (single contiguous `PARAMSTART..PARAMSTOP` range, `NLOOPS = 0`), and `hal_dss_hwa_is_done()` (poll-only `HWACCREG4.PARAMDONESTAT`, no ISR path — DSS-local `PARAM_DONE` interrupts exist but are out of scope here, matching the MSS driver's polling-only shape). Carries forward the same documented scope limits as the MSS driver: no real FFT/CFAR/log-magnitude/compression correctness validation (TRM defers to a separate Radar HWA User's Guide not available in this project), no individual `PARAMn_x` field API, no DMA-triggered param-sets or looped execution. ### Use Case / Rationale As a firmware developer, I need minimal DSS-side HWA bring-up/trigger/poll parity with the already-landed MSS driver, for firmware that runs signal-processing chains from the DSS core. ### Acceptance Criteria - [ ] `hal/dss/hwa/hal_dss_hwa.c`/`.h` implemented against this project's current `hal/registers/component/hwa.h`/`instance/hwa.h` - [ ] `testing/dss/hwa/test_dss_hwa.c` passes under `ctest` - [ ] Sanity-checked by deliberately breaking a register field/formula and confirming the test suite catches it, then reverting ### Functional Impact None — self-contained addition alongside the already-landed Mailbox/EDMA/VIM/DSS-ADCBUF/DSS-INTC/DSS-Cache drivers. ### Regulatory Impact None ### QMS Impact None ### Risk Impact No new risk — same documented scope limits as the already-landed MSS HWA driver (no signal-processing correctness claims beyond what TI's CSL headers and reference bring-up sequence support). Existing risk coverage sufficient. ### Related Issues / PRs Relates to #4, relates to #99, relates to #101, relates to #103, relates to #105, relates to #107, relates to #109

hoogv referenced this issue from a commit

2026-07-23 18:59:23 +00:00

feat(dss-hwa): DSS HWA driver implementation and host unit tests

hoogv referenced this issue from a pull request that will close it,

2026-07-23 18:59:41 +00:00

feat(dss-hwa): DSS HWA driver implementation and host unit tests #112

hoogv closed this issue

2026-07-23 18:59:54 +00:00

hoogv referenced this issue

2026-07-23 19:00:48 +00:00

feat: DSS RTI driver implementation and host unit tests #113

hoogv added this to the Revision V1.0 Launch milestone