Configuring and implementing an FPGA-based embedded system is not an easy task. Connecting various blocks of discrete intellectual property (IP) in a system using an FPGA, and making them all work together, continues to be difficult and time-consuming. Instead of designing a system themselves, engineers need a solution that can be quickly configured to closely match their design’s required functionality, for the lowest possible cost. A solution that combines FPGAs with a hardware-based system-on-module (SOM) approach makes this possible.
One of the major benefits of using an FPGA-based embedded system is the ability to re-use a wide variety of already-designed functional blocks. In the form of soft IP blocks, these functional blocks can be combined to create reference designs that are optimized for specific industry segments. Using a systems-on-module approach provides an excellent target platform for compartmentalizing the FPGA-based IP into a form factor that delivers greater versatility than a single-board solution.
Combining a system-on-module approach with FPGA technology produces an environment with several advantages. First, integrating peripheral logic and optimized IP in the FPGA on the system-on-module cuts NRE costs and time to market. Second, this solution can help avoid design obsolescence by providing a flexible, reusable platform which can be configured with a different mix of IP blocks for each application. Finally, the system-on-module can be used as both development hardware and an off-the-shelf component in low volumes. The IP blocks and modular hardware can be later optimized for production quantities.
A Modular Approach
The basic architecture of an SOM approach that uses FPGAs divides the system hardware into selectable combinations of functional blocks, delivered in the form of a module. The modules can be plugged together in different combinations to create customized systems which can be geared toward a specific application. To build a system, an engineer simply selects the required modules to satisfy the application’s needs.
The FPGA-based SOM approach from Ultimodule includes a system-on-module and a set of optional expansion modules, measuring 40 mm x 65 mm. The system-on-module contains a set of pre-installed FPGA-based IP blocks, which are field-proven reference designs optimized for a particular industry segment. The system-on-module itself is a complete system-level solution. A set of interchangeable expansion modules for peripheral I/O, communication, or memory functions are provided for customizing the system even further. These expansion modules are also based on FPGA technology to enhance the flexibility of the overall system.
The system-on-module includes the processor, memory, and a set of foundation-level functional blocks incorporated in an FPGA (see Figure 1). These foundation-level blocks support the fundamental operation of the SOM itself and typically include such functions as a memory controller, simple communications, timers, and a CPU interface.
 |
| Figure 1. System-on-Module optimized for Human-Machine Interface (HMI) Display Control Applications. |
Additional gates in the system-on-module’s FPGA are dedicated to a second set of functional blocks that complete the requirements for a specific application. These functional blocks can include components such as a video controller, a matrix keyboard controller, and a CAN 2.0 network interface. These application-level blocks transform the base system into a specific solution geared toward the requirements of a particular application. In this case, the application is a human-machine interface (HMI) used in a CAN network as an operator panel that displays status and controls operation of an injection-molding machine.
Multiple Mixes of IP
The system-on-module delivers a processor, run-time software, and the mix of IP in the module’s FPGA that includes basic control logic and application-specific logic to provide an optimized system-level solution. For some applications, this compact module is enough to satisfy the requirements of a simple sub-system, such as a human-machine interface (HMI) display controller. In sub-systems with more complex I/O and communication requirements, such as one used for industrial control and communication bridging, a developer or system integrator may need additional expansion modules to complete the system’s hardware implementation.
Figure 2 shows the SOM approach used in a more complex sub-system in the same CAN network. The FPGA in the system-on-module contains the same foundation-level building blocks. However, the application-level blocks—the video and keyboard controllers—have been replaced with a medium-speed serial data link. This inter-module data link is used to connect the system-on-module of this second sub-system to a set of expansion modules that monitor and control the injection-molding machine itself.
 |
|
Figure 2. System-on-Module Optimized for Industrial Control and Communication Bridging Applications.
|
Instead of creating a new design from scratch for each sub-system, an integrator or developer can use the pre-integrated mixes of FPGA-based IP — and the modular hardware — as if they were traditional components. Either the soft IP or the modular hardware, or both, can also be customized using design services to meet the requirements of the final sub- system.
The Serial Data Link
The serial data link is the crucial element in the modular system because it extends the scope of the solution by providing access to data collected by functional blocks spread over several FPGAs on multiple modules. This data link connects multiple modules together through a range of standard carrier boards, which provide physical-layer connectivity between the modules.
The major design criteria for the data link included simplicity, low latency, interrupt support, and error handling.
For simplicity, the serial data link is implemented as a daisychain network, with one Master node and one Slave node for each FPGA that contains application-level functional blocks. The Master node is located in the system-on-module. Each peripheral I/O module contains a uniquely addressed Slave node. The Slave node transmits data from the peripheral devices on an expansion module in response to data commands from the Master node. Slave nodes cannot communicate directly with each other.
For low latency, the data link uses a command response format. The Master node initiates a command over the serial network to a specifically addressed Slave node which must respond to the request. The Master command is a single 16-bit transmit (TX) message and the Slave response is a single 16-bit receive (RX) message. This single TX/RX message pair means that any Slave node in the daisychain network can be addressed and data accessed in as few as two TX/RX cycles, although a typical transaction sequence generally requires more cycles.
To support interrupts, during each TX/RX cycle the master sends a TX frame to the addressed Slave node, and the selected Slave replies with an RX frame. While the RX frame is being returned to the Master, other Slaves in the upstream path can modify this RX frame to notify the Master that there is a pending interrupt on another Slave node.
To provide protection against errors, each TX and RX frame is protected with hardware-based cyclic redundancy check (CRC) error detection, which gives 100% coverage on single- and double-bit errors. For burst errors, coverage is 100% for 1-, 2-, 3- and 4-bit “0” burst and for 1-, 2- and 3-bit “1” burst.
From a system control perspective, each Slave node connected via the serial link acts like a device attached to a network, since each “device” can be individually addressed and sent command and control messages. Additionally, each Slave node supports up to 16 megabytes of memory access. Although the Slave node can address this much memory, most modules are designed with the Slave node using this memory access capability as memory-mapped I/O. This means that the Slave node simply maps this memory space to several data and command registers that access the functional blocks in the expansion module.
For the injection-molding machine control system shown in Figure 2, the serial link was used in its default configuration: a single-wire serial bus that daisychains Slave expansion modules to the Master system-on-module. This default single-wire data link supports mid-bandwidth data-transfer requirements. For higher data-transfer capabilities, a higher-speed configuration is available.
In traditional FPGA-based communication systems, if the expansion module’s FPGA becomes corrupted, the Slave can no longer communicate with the Master. To overcome this problem, the Ultimodule serial data link includes a backup recovery mode. This recovery mode lets the serial link act as an interface to serial Flash memory so the Master node can remotely reprogram the FPGA. To accomplish this, each Slave expansion module has a secondary data link Slave node hard-programmed into a CPLD (which also serves as the configuration device). Upon boot-up, the CPLD performs a CRC check on the configuration bitstream while downloading it to the FPGA. If the CRC check fails, the secondary node automatically alerts the Master of a node failure, and the Master can download a replacement FPGA bitstream to the Slave’s SPI Flash. When the Slave expansion module reboots, the CPLD reloads the new bitstream.
Conclusion
The use of FPGA technology provides numerous benefits to embedded system design. These benefits include the ability to fix design bugs in the FPGA hardware, upgrade a system in the field, or simply swap out hardware functionality without redesigning the physical board that contains the FPGA.
In this article, we discussed a specific FPGA-based SOM approach to embedded system design, and how the same basic system-on-module can be used to implement two different mixes of soft IP blocks from a set of pre-tested, pre-integrated reference designs. These two system-on-module IP mixes were used in the final design of an industrial injection-molding machine: one for HMI display control, and one for process control and communications.
