For product development teams engaged in control system design, power electronics, and advanced testing, the choice between CPU (Central Processing unit) and FPGA (Field-Programmable Gate Array) execution on Speedgoat real-time target machines can determine whether a project meets its performance targets or encounters sampling bottlenecks. This article explains how Speedgoat’s architecture, integrated with MATLAB and Simulink, enables engineers to deploy algorithms on the most appropriate compute core – CPU or FPGA – and thereby achieve deterministic, high-frequency sampling required for modern applications.
Introduction to Speedgoat
Speedgoat is a Swiss-based provider of real-time simulation and testing systems, specialising in hardware-in-the-loop (HIL) test benches, rapid control prototyping, and electrification test solutions. The company’s portfolio centres on scalable real-time target computers that are expressly designed to work with MathWorks’ Simulink Real-Time operating system. These systems combine multi-core CPUs, Simulink-programmable FPGAs, and a broad range of I/O modules to support applications from early algorithm validation to controller verification on rack-level HIL test rigs.
Speedgoat’s value proposition lies in its tight workflow integration with MATLAB and Simulink. Engineers can design, simulate, and instrument real-time applications directly from the Simulink environment, then deploy to Speedgoat hardware with minimal manual coding. This model-based design approach reduces the need for embedded C programming or HDL (Hardware Description Language) expertise while maintaining deterministic execution and microsecond-level I/O latency.
Role of MATLAB and Simulink in Speedgoat Solutions
MATLAB and Simulink form the software backbone of Speedgoat’s real-time ecosystem. Simulink Real-Time provides a hard real-time operating system that runs on Speedgoat target computers, enabling deterministic execution of models developed in Simulink. Within this workflow, engineers construct control algorithms and plant models as block diagrams, configure sample rates, and assign execution targets – CPU or FPGA – using Simulink’s partitioning tools.
When the model is built, Simulink Coder automatically generates optimised C code for CPU execution, while HDL Coder produces synthesised HDL for FPGA deployment. This dual-path code generation allows teams to run different parts of the same application on different cores: slower supervisory logic and communication stacks on the CPU, and fast inner control loops or signal conditioning on the FPGA. MATLAB further extends this capability through APIs and App Designer, enabling custom test automation, data logging, and real-time instrumentation without leaving the MATLAB environment.
The integration is plug-and-play; Speedgoat target machines are preconfigured with IP addresses and driver support, and appear as nodes in the Simulink Real-Time Explorer. Engineers can connect, monitor, and tune parameters in real time, accelerating the transition from desktop simulation to physical testing. This seamless workflow is particularly valuable for teams adopting model-based design, as it minimises hand-coding errors and shortens development cycles.
Understanding CPU and FPGA in the Speedgoat Context
In Speedgoat systems, the CPU and FPGA represent two distinct compute paradigms, each suited to different classes of real-time tasks. The CPU is a general-purpose processor – typically a multi-core Intel Xeon or similar – running a real-time operating system at clock speeds of 3–4 GHz. It executes sequentially, fetching and interpreting instructions from memory, which introduces variable latency due to cache misses, branch prediction, and operating system interrupts. Despite this, modern CPUs deliver high throughput for complex, branching algorithms and are well-suited to sample rates in the 1–20 kHz range, occasionally up to 100 kHz for simpler models.
By contrast, an FPGA is a reconfigurable hardware device composed of logic blocks, lookup tables, and embedded memory that can be programmed to implement custom digital circuits. Unlike the CPU’s sequential execution, an FPGA processes data in parallel, with all logic paths operating simultaneously on each clock cycle. This parallelism yields deterministic, nanosecond-scale latency and enables closed-loop sample rates in the MHz range – essential for applications such as high-bandwidth current control, vision pre-processing, or emulation of fast power electronic switches.
Speedgoat target machines integrate both cores on a single chassis, allowing co-simulation: the CPU handles higher-level tasks (e.g., state machines, communication protocols), while the FPGA manages time-critical loops and low-latency I/O. Within Simulink, engineers partition their model by assigning subsystems to “CPU” or “FPGA” blocks; HDL Coder then synthesises the FPGA portion, while Simulink Coder compiles the CPU portion. This hybrid architecture provides flexibility: teams can start with CPU-only execution for rapid prototyping, then migrate critical paths to the FPGA as performance requirements tighten.
CPU vs. FPGA for Real-Time Execution: Impact on Product Development
Selecting the appropriate Speedgoat core – CPU or FPGA – has profound implications for product development timelines, validation fidelity, and eventual embedded deployment. The decision hinges on three interrelated factors: required sample rate, algorithm complexity, and I/O latency tolerance.
For applications with modest bandwidth demands – such as thermal management controllers, vehicle dynamics simulators, or battery state-of-charge estimator – CPU execution is often sufficient. A typical quad-core Speedgoat Performance target machine, running at 3.1 GHz, can sustain closed-loop rates of 10–50 kHz for moderately sized models. This allows teams to iterate quickly, leveraging Simulink’s automatic C code generation and avoiding the additional synthesis time associated with FPGA workflows. In one illustrative case, an automotive supplier developing a predictive energy management strategy for a hybrid vehicle deployed their entire model on the CPU, achieving 20 kHz sampling with ample margin for future feature additions.
However, when sample rates exceed 20–100 kHz, or when I/O latency must be minimised (e.g., for current-loop control in inverters or motor drives), FPGA execution becomes necessary. FPGAs on Speedgoat machines offer analogue and digital I/O with sub-microsecond latency, enabling deterministic sampling at MHz frequencies.
The choice also affects development risk. CPU-based workflows are faster to iterate: build times are measured in seconds, and debugging can be performed using Simulink’s real-time scopes and parameter tuning. FPGA synthesis, by contrast, can take minutes to hours, depending on model size and target device. Consequently, teams often adopt a hybrid strategy: prototype on the CPU to validate algorithm logic, then migrate time-critical sections to the FPGA once performance bottlenecks are identified.
From a product lifecycle perspective, early FPGA adoption can de-risk embedded deployment. If the final controller will run on an FPGA or ASIC, developing and testing on a Speedgoat FPGA from the outset ensures that timing, resource, and numerical precision issues are uncovered during validation rather than during production. Conversely, if the embedded target is a microcontroller, CPU-based HIL testing may suffice, with FPGA reserved for plant emulation (e.g., motor or grid models) requiring high fidelity.
Cost and resource planning also play a role. FPGA-enabled Speedgoat machines carry a premium, and HDL Coder requires additional licences. Teams must weigh these costs against the performance gains and risk reduction. In practice, many organisations begin with CPU-only systems for RCP, then upgrade to FPGA-capable racks for HIL testing of production controllers.
In summary, Speedgoat’s real-time target machines, tightly integrated with MATLAB and Simulink, offer product development teams a flexible platform for deploying control algorithms on either CPU or FPGA cores. CPUs provide rapid iteration and sufficient performance for sample rates up to ~100 kHz, while FPGAs deliver deterministic, MHz-range execution for time-critical loops and low-latency I/O. By partitioning models intelligently – supervisory logic on the CPU, fast inner loops on the FPGA – engineers can optimise both development speed and validation fidelity. For companies designing high-performance controllers, selecting the right Speedgoat core is not merely a technical choice; it is a strategic decision that shapes testing capability, time-to-market, and ultimately, product reliability. [speedgoat]
