ENGINEERING NOTES

Methods for systems that have to work.

Concise field guides for turning algorithms, programmable logic, firmware and verification infrastructure into accepted product capability.

SYSTEMS · FIELD NOTE

From idea to an executable acceptance contract

Why requirements, models, partitions and tests should share one persistent evidence thread.

Read the field note →
ARCHITECTURE · FIELD NOTE

Choosing the RTL, DSP, firmware, host and cloud boundary

A scorecard based on measured target behavior rather than organizational habit.

Read the field note →
DSP / SDR · FIELD NOTE

Adaptive radio without surrendering determinism

Where ML helps spectrum systems, and where replay, fallback and waveform evidence remain mandatory.

Read the field note →
EMULATION · FIELD NOTE

Emulation as reusable product infrastructure

Release models, workloads, transactors, debug and operations as one platform.

Read the field note →
AI ENGINEERING · FIELD NOTE

Agentic engineering without losing provenance

Bounded generation, independent critique, deterministic measurement and human authority.

Read the field note →
DELIVERY · FIELD NOTE

Pay for accepted evidence, not generated volume

A practical structure for front-loaded capacity and back-loaded milestone compensation.

Read the field note →
FIELD NOTE 01

The evidence thread is the product memory.

Give every consequential requirement a persistent identity, owner and planned proof method. Connect it to executable reference behavior, allocation decisions, interfaces, implementation and the exact release result.

A failed target test can then return to the responsible requirement, model, partition or implementation. That feedback loop matters more than generating another document.

See the eight-gate method →
FIELD NOTE 02

Partition from a measured platform profile.

Profile rate, burst behavior, memory, I/O, precision, latency, power, thermal headroom, software environment, lifecycle and unit economics. Score candidate allocations across FPGA, DSP, CPU, GPU, firmware, host and cloud.

Dataflow and deterministic concurrency often favor programmable logic. Complex control and high change rate often favor software. The winning boundary is the one whose full-system budgets close with credible margin.

FIELD NOTE 03

Put AI around a trustworthy radio core.

AI/ML can help classify emitters or interference, prioritize spectrum attention, explore configurations, cluster failures and adapt operating policy. The waveform, framing, timing and safety-critical fallback remain deterministic and independently testable.

A credible AI and SDR release records the model and dataset, bounds confidence and latency, replays representative and adversarial channels, exposes the selected action, and returns to a known operating mode when confidence or resource limits fail.

FIELD NOTE 04

An emulator is equipment. An emulation service is a product.

The service needs versioned model releases, supported use cases, transactors and peripherals, firmware-ready boot paths, representative workloads, regression throughput, debug recipes, triage ownership and utilization feedback.

Acceptance is not “the design mapped.” It is that intended teams can reproduce the release, execute useful software or workloads, observe failures and close them at the required cadence.

FIELD NOTE 05

AI changes throughput. It does not lower the proof bar.

Use agents to draft requirements, transform governed source models, explore options, propose implementation, generate test scaffolding and cluster failures. Keep architecture gates, security boundaries, interface ownership and releases under accountable human authority.

Record model, prompt, tool and input versions. Keep generation and critique roles separate. Treat generated RTL, firmware and tests as untrusted until compilation, static analysis, simulation, formal methods where useful, target execution and correlation provide evidence.

FIELD NOTE 06

Back-load against engineering evidence, not business hope.

A sound risk-share pays a current floor for committed capacity, then accrues a bounded success tranche against several short, useful milestones. Each gate specifies the baseline, test environment, target, tolerance, client dependency and authorized acceptor.

Do not tie an engineering fee to certification, fundraising or revenue unless attribution and control truly exist. Hybrid models are more credible because they share delivery risk without pretending either party controls every external dependency.

See the commercial models →

Have a system question that deserves an evidence-backed answer?

Discuss the decision