Research date: 6 September 2026. This is a design proposal informed by primary literature, vendor documentation, and read-only inspection of the existing stack. It is not an implementation, benchmark, novelty proof, or change to an accepted contract. Local test results discussed below are retained project evidence; no batteries were rerun for this research.
FPLA is worth investigating as a programmable fabric for servicing Loci under explicit floor contracts. Its nearest technical relatives are coarse-grained reconfigurable arrays, dynamic dataflow processors, virtual-actor runtimes, and capability architectures. The plausible contribution is their integration around the stack's precise identity, transition, currentness, and evidence semantics, together with measurements showing that the integration pays.
The important unit distinction is: a Locus is a semantic entity; an array element is a physical service resource. Many dormant Loci may share a smaller set of service elements. Placement changes do not create new Locus identities.
One correction to the initial brainstorming: the existing readiness model says that the floor knows possession, while readiness is determined above it. A hardware readiness engine can sit beside the floor, but making the floor infer demand would be an architectural change. Preserve that separation even when the components share a chip.
| Primary source | Relevant mechanism | Implication for FPLA |
|---|---|---|
| Plasticine, ISCA 2017 | Reconfigurable compute pipelines coupled to banked pattern memory units and address generation. Its evaluation uses a cycle-accurate simulator. | Design state storage and access alongside compute. Its reported speedups do not predict FPLA performance. |
| WaveScalar architecture | Instructions occupy processing elements for repeated execution and communicate through a hierarchical interconnect; placement changes with the working set. | Persistent placement and computation moving through an array have substantial precedent. The Locus contract must supply the additional content. |
| AMD AI Engine components | Two-dimensional arrays combine programmable processors, local memory, and tile interconnect; applications use dataflow graphs of kernels. | An existing example of the physical ingredients, with different application and execution semantics. |
| Stream-Dataflow Acceleration, ISCA 2017 | Separates repeated dataflow computation, memory streams, and scratchpad reuse. | A useful model for separating Locus control traffic from bulk state movement. Its target workloads favor long phases and regular streaming. |
| Revet, HPCA 2024 | Compiles a threaded programming model onto vectorized reconfigurable dataflow execution. | A thread-shaped programming surface does not necessarily imply a conventional thread implementation. FPLA comparisons must concern mechanisms and contracts, not vocabulary. |
| The Reduceron Reconfigured | An FPGA processor designed for sequential graph reduction. | Graph-reduction hardware is established prior art, although this is not the same calculus or floor architecture as TRVM. |
| Interaction nets processor in Clash | Public implementation project for an interaction-net processor. | A directly relevant implementation to inspect before claiming a new hardware reduction idea. The repository's existence does not establish production maturity or comparative performance. |
| Orleans virtual actors | Runtime management of logical actors and distributed resources. | Stable logical identity and runtime-managed residency are not new by themselves. Compare the exact execution, migration, and recovery guarantees. |
| CHERI | Hardware capabilities support memory protection and software compartmentalization. | A model for small hardware-enforced restrictions. This does not establish one-use authority, durable currentness, or the WEK laws; those need their own mechanisms. |
| AMD Dynamic Function eXchange | Changes FPGA regions in an active design; decoupler components isolate regions during reconfiguration. | Reconfiguration needs explicit boundaries. Replacing logic does not itself preserve the application state or authorize a successor. |
| Dynamatic and resource sharing research | Dynamically scheduled dataflow circuits; buffering and resource sharing affect progress and deadlock. | Bounded mailboxes alone do not establish end-to-end liveness. Routing, output capacity, and shared-resource scheduling need explicit analysis. |
WRL and Forge: use the existing semantic lowering path as the frontend. A placement description belongs beside the semantic artifact. Moving a semantically unchanged graph to a different tile should not redefine its semantic identity. Record the implementation and placement separately using the stack's existing provenance conventions. The WRL README distinguishes its narrow implemented Core from the much broader authored draft; a hardware target must name the supported subset.
TRVM: a candidate reduction engine and correctness oracle. Its README explicitly separates schedule-independence from the additional boundary-port ownership and monotone-export discipline used for distributed reduction. Confluence is not a substitute for those rules. It also does not make external effects, authority consumption, or placement recovery coordination-free.
ComputeDriven: supplies Locus possession, whole transitions, selection/residency/placement distinctions, readiness admission, and transfer/currentness work. This is the strongest existing foundation for the FPLA contract. The R6 freeze has a declared deployment-controlled-anchor, protocol-disciplined-supervisor, process-death profile. Putting a controller in hardware would not automatically extend that claim to power failure, hostile hosts, or replicated anchors.
WEK: supplies enforcement requirements for the integration. The inspected R0 census is a dated baseline of existing substrates and explicitly says it does not measure implemented WEK code. Treat it as requirements and historical evidence, not proof of a completed hardware enforcement kernel.
TRAAVIIS and the wider evidence stack: retain the distinction between producing an execution result and admitting that result as evidence. A fast array completion is not automatically a warrant for the claim attached to it.
Keep transition computation on existing CPU floors. Add an array-side engine for bounded mailbox storage, ready-set maintenance, queue selection, and command delivery. Preserve the rule that an event changes readiness but executes no floor command by itself.
This targets workloads with many dormant Loci, short bursts, and small transitions. It tests whether readiness bookkeeping and dispatch dominate the current cost. Its main risk is that transfer to the accelerator costs more than the work saved. An in-process software version should therefore precede an off-chip implementation.
Use processing elements for a finite supported set of reduction operations, with banked storage for graph data, bounded local work queues, and explicit cross-partition exports.
The difficult parts are allocation, pointer updates, memory conflicts, graph growth, and interconnect traffic. Making a rewrite operation fast is insufficient if finding its operands and placing successors dominate. Do not map an entire possibly unbounded normalization to one supposedly bounded floor transition. The bridge must expose completion boundaries consistent with the declared semantics.
Separate readiness service, floor enforcement, reduction, and bulk memory movement into cooperating resources. Some resources may initially be CPU software; others may later be FPGA logic or dedicated hardware. A hardware implementation could place a small invariant-enforcing shell around programmable compute.
This is the strongest long-term FPLA interpretation. It is also the most expensive to validate, because a result crossing from an accelerator into authoritative state must remain bound to the work that was actually authorized and executed.
Recommendation: model C as the destination, test A and B independently, and combine them only after measurements identify a useful division of labor.
An initial service element could expose:
A current binding to a Locus and its relevant state revision and holder incarnation.
A declared transition profile and bounded access to the state that profile uses.
A command input from the scheduler, separate from event arrival.
A successor-or-refusal result with the required outcome information.
A transfer interface whose activation follows the existing authority decision.
These are conceptual interface obligations, not a proposed new frozen instruction vocabulary. Reuse existing operations first and derive any extra operation from a concrete missing behavior.
The invariant shell checks what remains invariant when configuration changes: applicable authority, binding, admissibility, state-installation rules, and exclusive service. Programmable logic selects implementations and permitted policies within those constraints. A configuration that changes a rule's meaning needs an explicit semantic change, not a silent placement update.
A Locus waiting for an external result holds durable or retained semantic state and readiness data, with no mid-transition continuation. Physical pipelines can still stall internally on memory or routing; that must not expose partially installed semantic state. Semantic atomicity is not a claim that every implementation finishes in one clock cycle.
Separate frequently used state from historical evidence. The floor census notes that its evidence ring occupies a large portion of the measured context and moves during operations that do not use it. Explore keeping evidence in a separate retained structure while transitions access only the fields they need. Preserve evidence ordering, retention, and refusal semantics. Smaller state traffic is a hypothesis to measure, not permission to omit evidence.
Keep the logical readiness home stable while testing physical distribution. A stable home per Locus need not mean all homes are served by one processor. First retain the current home arrangement as a control; later test partitioning homes across resources. Home migration is a separate protocol change and should not be bundled with Locus placement.
Let the compiler offer locality hints. WRL topology and TRVM partitions can indicate communicating groups and likely reusable state. The runtime can use those hints with observed demand. A hint grants no authority. Keep physical locality separate from semantic routes and preserve the existing result identity across legal placements.
Exploit computational reuse before moving computation. TRVM's canonicalization and computational-memory work suggest a useful third choice beside stay or move: reuse a valid existing result. The cache key must bind the appropriate semantics, inputs, and rules. Reusing a pure result must not replay an external effect or bypass evidence admission. This idea follows from the local TRVM findings and remains unmeasured in an FPLA setting.
Distinguish placement from logic reconfiguration. Rebinding a Locus to an already compatible service element is a lighter conceptual operation than loading new FPGA logic. Start with fixed elements and configurable tables or programs. Hardware partial reconfiguration becomes useful only if changing element implementations earns its own cost.
Write a reference machine for two independent service elements. Retain stable readiness homes, whole transitions, named refusals, and exclusive service. Compare every observable transition with the software reference under the same declared policy.
Add four elements without changing transition semantics. Measure where contention appears: readiness service, memory banks, routing, transition execution, or evidence output. Element count alone is not a scaling result.
Compare static placement with one explicit move and an operational adaptive policy. The adaptive policy may use current observations; it must not consult the paired STATIC run. Keep offline counterfactual analysis separate.
Use several workload families. Sparse independent events, causal chains, bursts, a small real WRL workload supported by the implemented subset, and TRVM graphs with different locality and state-growth behavior. Include a deliberately poor fit such as very small off-chip commands or dense numeric work already served efficiently elsewhere.
Compare matched guarantees. Include optimized plain C or Rust state machines and an event-driven actor/runtime baseline with equivalent admission and state semantics. Price added durability in a separate pass, then test the integrated system under that profile.
Prototype one hardware path only after profiling. Use simulation and FPGA synthesis to measure resources, timing, and memory limits. Hardware simulation timing, FPGA results, and ASIC estimates must remain separate evidence categories.
Primary outcomes: useful successful transitions, completion latency distributions, per-Locus progress and starvation, state bytes moved, refusal counts, handoff interruption, CPU work, and evidence traffic. Measure energy only with an appropriate instrument; lower instruction count does not establish lower energy. Report both fixed-horizon progress and fixed-work completion, since admissions and completions can differ between placements.
Critical checks include: no duplicate service during movement; no event lost without its declared disposition; refusal preserves the required semantic state; dependent work observes the correct completion class; stale placement cannot authorize execution; and routing or output backpressure cannot create an unaccounted deadlock. Reserve output capacity or define another explicit mechanism before committing a transition that must emit downstream work.
Confluence can support comparison of normal forms; it does not imply identical intermediate traces. Compare canonical films where the WRL profile requires them, and compare only the equivalence relation actually promised by each execution profile.
FPLA already has a hardware meaning: Field-Programmable Logic Array, documented in the 1989 Signetics PLD manual. Use the expanded name or ComputeDriven FPLA in external discussion to avoid ambiguity. The exact-phrase search did not surface an established Floor Programmable Locus Array architecture; that is not proof of novelty.
A defensible research question is: can a programmable array preserve ComputeDriven's declared Locus transition and currentness contracts while improving useful progress per unit of movement, execution, and evidence cost?
The architecture earns a distinct identity if its interface makes those guarantees explicit and its implementations preserve them across placements. A new acronym or a fast graph-reduction datapath alone would not establish that contribution.
Paths below identify the read-only sources, not newly generated deliverables. Historical documents retain their own dates and scopes.
/home/travis/ProjectAmp2/TRVM/README.md
/home/travis/ProjectAmp2/TRVM/FINDINGS.md
/home/travis/ProjectAmp2/TRVM/docs/spec/RELATED_WORK.md
/home/travis/ProjectAmp2/TRVM/FORGE_SEMANTIC_IR_v1_MEASURE.md — historical pre-freeze memo; not used as current closure evidence.
/home/travis/ProjectAmp2/WRL/README.md
/home/travis/ProjectAmp2/WEK_R0_FLOOR_CENSUS_V0.md
/home/travis/ProjectAmp2/WEK_R0_FINDINGS.md
/home/travis/ProjectAmp2/WEK_R0_PRIOR_ART_MATRIX.md
/home/travis/ProjectAmp2/computedriven/docs/readiness-model.md
/home/travis/ProjectAmp2/computedriven/docs/sflr-r2.md
/home/travis/ProjectAmp2/computedriven/receipts/R6-FROZEN.md
Related task records for compute driven shared-floor multiplexing and full-stack development, including the R7.2.1A review qualifications.