Overview 

The ACE90011 is a high-velocity, deterministic hardware accelerator designed for the real-time execution of Extended Kalman Filter (EKF) algorithms. It provides a production-ready "Math-to-Silicon" pipeline that transforms complex state-estimation mathematics into high-frequency, bit-perfect FPGA logic. 

By offloading recursive mathematical kernels from a system’s primary processor, the core enables extreme computational throughput with zero execution jitter. 

With its  130K operations per second, the ACE90011 may be used, in the Radar and EW field, to enable “pulse-by-pulse” tracking and, in a multi-sensor network, to fuse multiple sources in real time. 

The core is engineered as a universal mathematical fabric for high-stakes tracking and navigation environments. It is specifically optimized for:

• Multi-Sensor Fusion: Tracking targets using asynchronous data from stationary or mobile sensor platforms.

• Flexible Observation Modeling: Processing any combination of sensor inputs, including Range, Azimuth, and Elevation. The architecture allows for the handling of non-measured quantities by setting their corresponding observation values to a mathematically large displacement, maintaining filter stability across diverse sensor types.

• Dynamic State Estimation: Performing high-frequency state projections and covariance updates for autonomous robotics, aerospace navigation, and defense-sector target acquisition.

The ACE90011 maintains a surprisingly lean resource utilization footprint that enables its implementation on the majority of the FPGA models.

The core is optimized for a mid range FPGA ( Artix-7), but ACE can easily port on any customer-selected FPGA (any vendor).  

While the core is fully functional, ACE internal development procedures provide the possibility for the customer to adapt to their needs:

• The algorithm

• The FPGA model

• The latency/resources trade off

• The precision/resources trade off

• Memory map

• Core interfaces (e.g. the BRAM interfaces can be set to AXI)

Key Features 

• Deterministic  1536 cycles Latency

• Max Clock Frequency: 200 MHz

• 130K operations per second at the max frequency

• Utilization less than 20% of the resources on a budget friendly  XC7A100TCSG324-1

• Portable across FPGA families and vendors.

• BRAM-based control interface

Theory of operation 

The core executes a complete Extended Kalman Filter cycle, including the coordinates transformation necessary in order to track a target with sensor(s) installed on a moving platform or using a distributed network with sensors placed on multiple moving platforms.

The core execution may be functionally divided in 4 stages to estimate the ECEF coordinates of the target starting from the measurements (true bearing, true elevation and range) performed by a sensor, the sensor position at the time of the measurement and the time of the measurement itself.

The core is completely stateless, meaning that it can be used for multiple targets/sensors in time sharing. At the same time, it is designed to retain in memory some of the variables (e.g. Q matrix, R matrix) and to overwrite the old results (starting point) with the new ones, in order to minimize the writing operations when possible.

Its design also allows asynchronous measurements, since all the quantities that need to be scaled over time are updated with the necessary delta time between the previous measurement and the new one.

In addition, while designed to manage three spherical coordinates, it can be used for sensors providing any combination of bearing, elevation and range, simply by scaling the corresponding element of the R matrix (e.g. for a sensor measuring only range, the sigma relative to the bearing and elevation may be set to a very high value).

The algorithm model was used both for the definition and validation (against a golden model) of the ACE90011 . 

A summary of the operations executed from the core is given by:

• Prediction (in ECEF coordinates)

• Computation of the predicted results (ECEF-> NED-> spheric coordinates)

• Computation of the Jacobian of the observation model

• State update

The ACE90011 core utilizes IEEE-754 Single-Precision (32-bit) floating-point arithmetic. 

Detailed Resource Utilization

The data below are representative of the AMD 7 series architecture. The percentage are relative to the budget friendly XC7A100TCSG324-1.

• Used CLB LUTs: 9562 (15.08%)

  • LUT as logic: 9505

  • LUT as Shift Registers: 130

• CLB Registers: 10751 (8.48%)

• CARRY4: 1531

• F7 Muxes:11 

• F8 Muxes: 1

• CLB Tiles (in the verification project): 3017 (19.03%)

• Used DSP: 9 (3.75%)

• Used BRAM36K: 4 (2.97%) 

• Used BRAM18K: 1 (0.37%)

DNA PORT: 1 

Timing and throughput 

The core runs on two different clocks:

• CLK_FAST with a maximum frequency of 200 MHz

• CLK_SLOW that shall run at 50MHz (phase aligned with CLK_FAST)

CLK_SLOW is used for the ACE90011 initialization, while CLK_FAST is used for all the runtime operations.

In the verification project, the timing was closed with 0.086ns timing margin and with 0 timing violations. 

Interfaces and operation flow 

The Multi-Sensor Extended Kalman Filter core is packaged as an AMD IP core. Figure 1 illustrates the verification configuration. 

Figure 1 

The core is fully controlled through read/write operations on a BRAM (optionally accessible via an AXI BRAM_CONTROLLER). The instantiated BRAM are 2 True Dual Port with port A available to the user and port B managed by the internal Math Engine.

The BRAMs have a width of 32 bits and a  depth of 1024 locations. The core uses the first 96 locations, with the remaining ones completely available for the user via port(s) A (port(s) B are assigned to the internal Math Engine). Port(s) A operates in the user clock domain; Port(s) B operates in the internal engine clock domain.

The memory Map is reported below:

Memory Map 

In addition to the BRAM interface, the core exposes:

• Two clock slave interfaces:

  • CLK_SLOW is used for the initialization and for the access to the DNA reader primitive ( 50MHz)

  • CLK_FAST is used to drive the internal computation engine (Max Frequency: 200 MHz)

• A BUSY pin that, when set to high, signals when the core is executing the initialization or its main function. 

The core, at power-up, performs an initialization sequence that lasts (with CLK_SLOW @ 50 MHz) less than 5000 ns. 

When the initialization is complete, the BRAM is populated with the DNA of the FPGA (see Memory Map).

Once the initialization is complete, the user may load the BRAM in accordance with the input reported in the Memory Map and,finally, set the START_CMD to 0x1.

The results are written in BRAM, in accordance with the memory map, after exactly 1536 clock cycles. The end of execution is communicated by the core by setting the START_CMD to 0x0 and via the BUSY PIN (BUSY=0 indicates the core is in the IDLE state, ready for the new execution).

When the START_CMD is asserted, the core performs the entire computation. Execution cannot be stopped. Writing on the BRAM first 96 addresses during the execution will produce undefined results and it is not supported. The execution will always complete in the specified 1536 clock cycle window. 

Note: if the USER_KEY is not correct, the core terminates in the specified timeframe, but produces unpredictable results. 

Results 

The ACE90011 hardware core undergoes rigorous validation via a "Math-to-Silicon" functional

pipeline. Performance results are verified using an explicit dual-filter co-simulation testbench

framework running alongside a single-precision software Golden Model. Both tracking profiles

process identical noisy, asynchronous multi-sensor spherical inputs (Range, Azimuth, Elevation)

generated by a target trajectory. For verification consistency, both filter instances are

deliberately initialized with an identical state displacement offset in local coordinates ([1000,

-2000, -200] meters in the NED frame) to test convergence capabilities and baseline recovery.

Functional and Bit-Level Execution verification 

Hardware-in-the-loop and post-placement testbench validation tracks exact register outputs

inside the dual BRAM memory structure across active filtering epochs. The validation script

continuously audits base-10 single-precision IEEE-754 hardware conversions directly against

the modeling equations. Crucial internal parameters—such as the Innovation Covariance matrix

determinant (DetS), inverted elements (si_xx), state error covariances (P_yz) , and

corrected state vectors—confirm exact architectural alignment with zero numerical divergence.

An extract of the simulated data is reported in Table 2.

Table 2

Tracking Performance & Coordinate Transformations 

To provide an informative, system-level interpretation of filter accuracy, absolute ECEF state

estimation vectors are transformed into the local North-East-Down (NED) frame relative to the

moving sensor platform position. This transformation uses Bowring's closed-form geodetic

equations mapped into a localized Direction Cosine Matrix.

Tracking performance analysis isolates individual spatial and velocity components against real

ground truth target data. The architectural choices result in unique tracking behaviors:

• High-Fidelity Initialization Tracking: The ACE90011 hardware core matches the single-precision software Reference Model right from the first filtering epoch (Stages 1 through 15). Because the core's internal pipelines are numerically optimized, the hardware completely eliminates transient quantization penalties or dampening, matching the software reference model's convergence path even under high initial tracking uncertainty. 

Steady-State Co-Simulation Alignment: As the state error covariance envelope contracts and settles into steady-state tracking bounds (Stages 20 to 60), the hardware core and the software reference model remain securely locked in lockstep. The error traces mirror each other asymptotically throughout the flight path, demonstrating complete mathematical stability and bit-validated functional alignment between the silicon execution and the simulation baseline. 

Figure 2 

Innovation Matrix Stability Analysis 

The structural integrity of the analytic matrix inversion engine (implemented inside the DSP

arithmetic pipelines via Cramer's Rule) is heavily bound to the Innovation Matrix determinant

(Det(S)). 

During initial track acquisition at Stage 1, the high estimation variance results in a

well-conditioned determinant value ( 9.09847 10-6 ). 

As the state updates lock onto the steady-state target flight path, the covariance fields decay uniformly. By Stage 60, the hardware matrix loops handle extremely tight innovation metrics down to 2.72167 10-11 without underflow clipping, showing robust numerical stability under high-dynamic scenarios. 

Licensing & Ordering Information 

ACE90011 is delivered as a pre‑packaged Vivado IP core, ready for integration through the AMD/Xilinx IP Catalog.

Each licensed core includes:

• Pre‑packaged Vivado IP (compatible with IP Catalog) including simulation model

• Memory map documentation (available in this datasheet)

• USER_KEY file for license activation

• Example project for rapid integration

ACE provides a USER_KEY value (64 bits) for FPGA Serial Number (DNA for AMD/Xilinx).

The keys are delivered in a simple csv file (a template is reported below):

The user may store the file with all the SN/licenses and select the key to load after reading the SN of the FPGA from the BRAM_PORTA interface of the ACE90011 core.

The envisioned process is the following:

1. The file with the keys is embedded the customer software

2. The customer software, waiting at least 5000 ns from power on, reads the FPGA SN from the BRAM_PORTA interface exposed by the  ACE90011 core.

3. The customer software retrieves the USER_KEY corresponding to the FPGA SN in the ACE provided USER_KEY file.

4. The customer software loads the USER_KEY via the BRAM_PORTA interface exposed by the  ACE90011 core.

The keys are generated on customer order.

In simulation, a demo DNA is used and the corresponding USER_KEY is provided in the file for a seamless experience.

Pricing is provided directly by ACE based on:

• Deployment volume

• License type

• Optional customization requirements

• Target FPGA family

Customers may request a quotation by providing their expected deployment profile and FPGA device list.