10 Key Tips
There are many factors to consider when selecting components and board-level solutions for a real-time embedded system. In this article, Pentek’s Rodger Hosking steps through 10 key tips that can help you significantly avoid risks and reduce development efforts.
Real-time embedded systems require a specialized class of electronic components from vendors that can support the special needs of systems integrators. Not only must the hardware products operate across a wide range of operating modes and environments, they must also deliver performance levels meeting critical objectives for specific applications. But other factors may be even more important.
Because each project is unique, good system development tools are essential for systems integrators to deliver operational systems to their final customers as efficiently and effectively as possible. And, the vendors of these hardware and software products must help integrators choose the most appropriate products, support them during development, and then offer life cycle management solutions for continued product availability.
By following some key recommendations in making product and vendor choices, integrators can significantly avoid risks and reduce development efforts. A summary list of these tips is shown in Table 1.
|Tips for Choosing Real-Time Embedded Systems
|Choose open standard products for best value and life cycle
|Define thermal management strategies early in the project
|Identify all interconnections, including speeds and levels
|If required, define early on how channels are synchronized
|Identify all necessary clocking, timing, and DMA functions
|Check for software, drivers, and examples of the above
|Look for high-level C libraries with underlying source code
|Identify which FPGA structures are included and supported
|Decide who performs the required custom FPGA design efforts
|Ensure graphical FPGA design entry tools support your boards
|Look for AXI4-complaint FPGA IP blocks from the board vendor
|Look for FPGA application examples from the board vendor
|Understand the board vendor’s applications support policy
|Look for the board vendor’s life cycle management programs
Open Standards: Increasingly, both government and non-government procurement requirements now mandate or encourage compliance with emerging open-system standards for embedded hardware components. Among the many benefits are interoperability among vendors, faster deliveries and competitive pricing. Instead of replacing an entire system for a new technology upgrade, open standards allow replacement of compliant modules more quickly and at far less cost, thus extending the useful life cycle of deployed systems.
By following open standards, vendors also benefit by focusing design and development efforts on their areas of expertise, while other vendors produce complementary and compatible products to round out the supply chain. This fosters government confidence in relying upon these open standards for future long-term programs.
Thermal management: As silicon device geometries continue to shrink, the power dissipation per transistor or element tends to drop, but this is often offset by increased clock rates. In addition, more elements can fit in a given size package, which drives power per device back up. Fine-pitch ball grid array packaging boosts component density of PCBs, often causing significant heat per slot in today’s embedded systems.
When designing a new embedded system, it is imperative that designers identify heat sources for each module as early as possible. For harsh environments, the popular VPX specification defines numerous available solutions, including forced-air, air flow-though, conduction-cooling and liquid cooling. Less demanding environments are often suitable for PC platforms. Selecting the most appropriate platform and thermal management strategies at the beginning of a project can avoid costly redesign cycles and serious delays.
System Interfaces: One of the toughest challenges in real-time system design is connecting system elements via data interfaces capable of handling the required traffic. Start by creating an overall system block diagram containing all essential elements, showing the data interconnect paths between them. Make sure that the interfaces on connected blocks match in type, bus width, lanes and data rates, and enter that information on the block diagram. Then, calculate and notate the worst-case data transfer rate required for each path, and compare it with the maximum path rate. This assessment of interconnect speeds will be an invaluable reference during development.
Some caveats to watch out for are interfaces that pass through several physical connectors, like a PCI Express link from an XMC module, through an XMC carrier that is plugged into a VPX backplane. Every connector can compromise maximum achievable rates. In these cases, modeling or functional test verification can help.
Shared resources, such as system memory, may have multiple contenders for access, resulting in compromised availability. Signals like received radar pulses can generate blocks of high peak rates separated intervals with no data. An elastic memory buffer (FIFO) may be required to take advantage of the low average rate for transfer across the interconnect path.
Synchronization: A growing number of phased-array antenna application, including 5G wireless, airborne and SAR radars, and directional communication links, all require multiple element antennas to support beamforming for receive and transmit (Figure 1). Each antenna element signal requires precisely controlled, programmable phase shifts relative to all of the other elements.
Each signal often connects to a dedicated data converter where DSP circuitry can easily handle these precise phase shifts. However, the data converters must acquire and generate each sample at exactly the same sample clock edge. For large arrays, the high number of elements may require synchronous operation across multiple boards or chassis to handle all the channels.
Such operation can only be achieved if this feature is part of the board design, and supported with timing and sync generators connected to each board. If channel synchronization is part of the system requirement, make sure the boards inherently include this feature with recommended connectors, cables and sync generators, because synchronization is otherwise nearly impossible to add later.
Installed Features: Real-time embedded boards playing typical roles in any system should include several basic functions supporting their assigned roles. For example, a single board computer (SBC) or PC motherboard will almost always implement a PCI Express root complex, system memory mapped across PCI Express address space, network interfaces, and CPU peripheral I/O like USB, serial and video. Standard CPU chip sets include virtually all of these functions, and supporting software drivers for Windows or Linux are commonly provided by the board vendor.
Other boards, like FPGA software radio modules with A/D and D/A converters, have far different roles and requirements. Commonly needed functions here include triggering, gating, time-stamping and synchronization engines that meet tight timing demands. Sample clock frequency synthesizers should accept a 10MHz system reference from an onboard GPS receiver or external source. DMA controllers must move data between the data converters and system memory through a PCI Express interface. Memory controllers for external SDRAM must buffer and capture real-time data converter streams, and communicate with the PCIe interface.
Unlike SBCs or PCs, which benefit from standard chip sets with low-level BIOS initialization, none of this exists for software radio boards. Instead, each of the hardware resources must be developed and incorporated in the FPGA. Equally important are the software libraries and drivers needed to make all of these resources work as required. Unless the board vendor includes them as factory installed features along with the supporting software libraries, the system integrator must develop, design, test, and document this on his own. To minimize risks, expense, and uncertain delays, systems integrators should make sure the board vendor includes these important resources.
Software Development: Although open-system architectures help with electrical and mechanical interoperability, all real-time embedded systems are a collection of diverse hardware elements that must be carefully configured for a specific, unique application. Unlike mass market PC boards with plug-and-play capabilities, most embedded boards must be explicitly configured to perform specific tasks, told how to utilize specific external input, output and timing signals and instructed what, when and how to communicate with other boards in the system. This is invariably accomplished by writing custom C programs that execute on the system controller, typically running Linux or Windows OS.
Even if an embedded board vendor provides C-callable functions for programmable hardware features, those offerings vary widely among vendors in their completeness and usability. Some offerings simply provide access to the programmable registers for the devices on the board, and the developer must use data sheets from the device manufacturer to figure out which bits to set. Even with a detailed block diagram of the board, this is very cumbersome.
In a far better approach, the board vendor offers high-level C libraries with well-documented command parameters that relate to the overall board-level operations performed, including references to other operations affected. Each of these high-level commands should include a well-organized underlying collection of low-level libraries to allow modification for specialized operations.
An even more elegant offering is a true API (application programming interface) with an API command processor program running on the system controller. In this way, API commands can be sent to the controller where they are parsed and executed, without needing to recompile a dedicated, executable C-program. API commands can be delivered to the controller via Ethernet, nicely supporting control and status functions of the embedded system from a remote client.
Last, numerous C program examples that illustrate typical operating scenarios are extremely valuable. They incorporate multiple high-level function calls with comments explaining the purpose of each, including why they must be executed in a specific order. Often these fully-tested examples can be incorporated directly into the final application to speed development. Of course, full C source code should accompany all library functions and code examples.
By selecting vendors offering these higher-level tools, systems integrators can complete their development tasks much more quickly and will be able to support changes and future upgrades far more easily.
FPGA Development: FPGA designs are really hardware designs, in which the basic hardware resources of the FPGA (thousands of gates, adders, multipliers, registers, switches, memories and interfaces) are wired together to create custom circuits. The wiring connection pattern is generated by software tools from the FPGA vendor that compile descriptive instructions from the designer to create a “bitstream.” When loaded into the FPGA, the bitstream implements the required interconnects for the required circuit, often simply called “IP.”
As mentioned earlier, the board vendor may install some standard IP functions at the factory. But many customers need to install additional custom IP within the FPGA for compute-intensive, real-time algorithms. These algorithms are often the systems integrators’ “secret sauce,” comprising their critical value-added contribution to the equipment. The ease of adding IP by the customer is highly dependent on the quality of the FPGA design package supplied by the board vendor.
First of all, look for a board vendor that includes most of the essential factory-installed features, like the ones described earlier. It will dramatically reduce the overall FPGA design effort. No one wants to spend years developing a JESD204 data converter interface or a DDR4 SDRAM controller!
Next, be sure the board vendor supplies FPGA source code for all of the installed IP modules in the HDL format matching your FPGA designers’ capabilities, usually VHDL or Verilog.
Ideally, all IP from the board vendor will be delivered as AXI4 compliant blocks to match the style of reference IP blocks from the FPGA vendor. AXI4 is a widely adopted interface standard derived from ARM technology that tackles most of the housekeeping chores for connecting one IP block to another.
Take full advantage of the graphical design entry tools from the FPGA vendor, such as Xilinx’s Vivado IP Integrator. All of the AXI4 blocks are visually displayed, representing the entire block diagram of the project with all interconnects shown. IP blocks and interconnects can be added, deleted, and modified with mouse clicks, and hyperlinked documentation is available by clicking on any block. After making the required changes, the project is recompiled to produce the new design and bitstream for the FPGA.
Choose a board vendor that delivers the entire FPGA project folder containing all the files needed to create the delivered FPGA IP, fully AXI4 compliant, with complete documentation, and ready to compile using the FPGA vendor’s tool suite.
New Technology: One of the major benefits of open standard COTS products is upgradability of existing systems with new technology by replacing a module instead of scrapping the system and starting over. Of course, depending on the upgrade, changes will often be needed to system software and perhaps even to some of the other hardware, interfaces or connectors. Still, this is a well-proven strategy for extending the useful life of deployed equipment.
Choose board vendors with a history of consistently delivering open-standards products based on each new generation of FPGAs, data converters, memories, and system interfaces. Look for high-level development tools from those vendors to simplify the migration of software and FPGA designs.
Applications Support: Because every embedded system tends to be unique, systems integrators invariably encounter first-time configurations of multi-vendor products that don’t seem to work as expected. Too often, each vendor blames another vendor for the problem, leaving the integrator on his own. Choose vendors with a proven track record of solving problems, regardless of who is at fault and share such experiences with other project teams.
Most board vendors offer contracts to provide technical support during the development phase, although the quality and timeliness of that support varies among vendors. When the support contract runs out, before they can get additional help, customers will either be asked to renew the contract, or for a credit card number. Some vendors offer free support for a limited time or number of hours, with payment required thereafter.
Be sure to ask any potential vendor for written descriptions of the applications support policies and costs before purchasing his products.
Life Cycle Management: Often, a significant concern for systems integrators is the increasing prevalence of component obsolescence, or end-of-life. This causes two major problems. Future component availability can jeopardize on-going production of enough boards to support multi-year installation program cycles. Also, 20- to 30-year maintenance contracts to support these fielded systems are at risk without components needed for repairs.
Systems integrators naturally look to the board vendors for help, and various strategies have emerged. The simplest one is to purchase and produce enough additional boards up front to cover all installations over the life of the program, plus spares to cover the expected number of failures. End customers usually balk at the cost of this approach.
A very cost-effective alternative is a bonded inventory component program. The board vendor purchases all of the active components needed for the production of the total number of boards required over the life of the program, plus extras for repairs. The customer agrees to pay for these components, which the vendor reserves for him in bonded inventory. When production is required, those parts are used and their cost is credited toward the new purchase.
Since components such as PCBs and hardware can always be purchased as needed for later production, the cost of this bonded inventory program is a small fraction of the cost of full production up front, and very attractive to most customers.
PUTTING IT ALL TOGETHER
As an example of these strategies developed over three decades, Pentek’s latest offering is the Model 5950 Quartz RFSoC 3U VPX module (Figure 2). Following the VITA 65 OpenVPX standard, this powerful software radio board combines eight channels of wideband A/D and D/A conversion, a wealth of Xilinx Zynq UltraScale+ FPGA resources, and a multi-core Arm processor to handle system controller functions.
Factory-installed features include IP for wideband data acquisition, triggering, timing, and multi-channel synchronization. A waveform generation engine creates analog signals from customer-created waveform tables or from an on-board frequency synthesizer and chirp generator. Linked-list DMA controllers move data from the board to and from the PCIe Gen.3 x8 interfaces and two 100GigE interfaces, each capable of sustaining 12GB/s.
All of these resources are supported with software development tools under the Pentek Navigator Board Support package. It includes a high-level API, C-language libraries, a command processor for the Arm, complete C source code, and fully functional starter applications. For custom FPGA development Pentek’s Navigator FPGA Design Kit contains the complete Xilinx Vivado project for the Model 5950, and a library of over 140 Pentek AXI4 IP modules for adding new features.
Pentek offers free lifetime applications support and well-development life cycle management and bonded inventory programs. By introducing a constant stream of industry-leading, open standard board level products with the latest data converters and FPGAs, Pentek helps systems integrators to take earliest advantage of the newest technology.
For detailed article references and additional resources go to:
Pentek | www.pentek.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2020 #354 – Get a PDF of the issueSponsor this Article
Rodger H. Hosking is vice-president and co-founder of Pentek, where he is responsible for new product definition, technology development and strategic alliances. With over 30 years in the electronics industry, he has authored hundreds of articles about software radio and digital signal processing. Prior to his current position, he served as engineering manager at Wavetek/Rockland, and holds patents in frequency synthesis and spectrum analysis techniques. He holds a BS degree in Physics from Allegheny College and BSEE and MSEE degrees from Columbia University in New York.