Technology
Accemic connects processor trace, live processing, source attribution, coverage, timing, control-flow evidence and independent acceptance on real targets.
The runtime-evidence architecture for embedded development.
AI can generate and change embedded software at machine speed. Accemic makes the result independently observable on the real target.
We connect processor trace, live processing, reliable object-to-source attribution, coverage, timing, control-flow evidence and independent acceptance into one architecture. Engineers can review the evidence. Established tools can consume it. CEDARtools.Forge can return it to the next iteration.
The architecture below runs from development intent on the left to the next decision on the right.
A technology stack, not a single point product
Accemic technology spans the observation source, line-rate processing, runtime reconstruction, source attribution, coverage, timing, external control-flow monitoring and independent acceptance.
These layers can operate as one architecture or become integration points within established processor, compiler, IDE, HIL, test, timing and AI-development environments.
| Layer | Accemic capability | Visible proof |
|---|---|---|
| Observation source | CTTE and supported processor trace sources | Public RTL, protocol and verification evidence |
| Live processing | CEDARbox and its FPGA processing architecture | Granted patents and product configurations |
| Attribution and evidence | Mapping, CEDARtools.Anchor, coverage, timing and validity | Publications, integrations and measurement records |
| Acceptance | CEDARtools.Forge | Guided pilot and a documented assurance boundary |
The architecture combines capabilities at different maturity levels. Each linked page states whether the relevant component is released, available for named configurations, provided as an integration, disclosed in patents or offered as a guided pilot.
From execution to decision
Requirements and acceptance criteria define the question. A candidate executes on the real target. Processor trace - Arm® CoreSight™, Infineon® MCDS, Intel® PT, RISC-V® N-Trace - reports what the core actually executed. Accemic validates and reconstructs that execution, attributes it to object and source artifacts, and turns it into evidence for coverage, timing, control-flow monitoring and acceptance.
- Identify. Bind the run to the exact executable, compiler information, target and trace configuration.
- Observe. Use the processor’s trace infrastructure to report execution independently of the application.
- Reconstruct and attribute. Process the stream while the target runs, rebuild control flow and map it to reviewable obligations.
- Evaluate and decide. Produce coverage, timing and control-flow evidence, retain unresolved regions and pass the result to a reviewer, partner tool or independent gate.
CEDARbox does this as a trace processor, not a trace streamer: reconstruction and analysis happen in the device while the target keeps running, subject to the sustained-rate limit of the named product configuration.
The processor already tells you what it did. The challenge is turning that stream into continuous, reviewable evidence fast enough to drive the next decision.
Generation has accelerated. Verification must become continuous.
Traditional trace workflows are designed for an engineer to investigate a selected incident. AI-assisted development can produce a new candidate faster than a human can inspect every run manually.
The feedback path therefore has to become continuous, structured and independent of the generator. That is the role of Accemic’s runtime-evidence layer.
Evidence stays attached to its limits
Passive trace analysis adds no application-side coverage counters or measurement runtime to the executable - probe-effect-minimal, and we would rather say that precisely than round it to zero. The trace source and transport still consume platform resources, and every result remains bounded by the verified target, bandwidth, mapping, timing and validity configuration.
Where CEDARtools.Anchor restores a source-level distinction, the anchor is part of the measured executable. Its identity, code-size effect and timing observations remain part of the evidence record.
Review measurement validity · See the capability matrix · Check supported targets
Explore the runtime-evidence flow
| Observe continuously | Process processor trace while the target runs instead of limiting observation to a short raw-trace capture. |
| Attribute reliably | Bind reconstructed execution to the exact program image and map it back to source without hiding ambiguity or orphan object code. |
| Establish coverage | Distinguish directly observed, Anchor*-supplemented, unresolved, deactivated and excluded obligations. |
| Measure timing | Observe real path and interference behavior over long campaigns and feed it into a defensible timing argument. |
| Monitor control flow | Detect execution outside an accepted model from a separate monitoring domain, within an explicit response boundary. |
| Close the loop | Turn target evidence into an acceptance result outside the generator and return it to the next controlled iteration. |
Every result carries executable identity, configuration, validity, provenance and unresolved gaps. How the run is validated
Sources
The trace facilities referred to on this page are specified in:
- Embedded Trace Macrocell Architecture Specification, ETMv4.0 to ETMv4.6 (Arm IHI 0064);
- CoreSight Architecture Specification (Arm IHI 0029);
- Intel 64 and IA-32 Architectures Software Developer’s Manual, volume 3C, chapter on Intel Processor Trace;
- RISC-V Processor Trace specification (E-Trace).
Review the architecture at the level you need
See what we do differently · Review the evidence · Discuss a technology or strategic fit