Skip navigation


3 Posts authored by: Mark-L-OSM

The Intel® Firmware Support Package was introduced in early 2013 as the “new way” of implementing hardware initialization on Intel®  platforms.  Replacing monolithic BIOS and earlier Unified Extensible Firmware Interface (UEFI) and the Intel® Boot Loader Development Kit (Intel® BLDK) packages, Intel Firmware Support Package gives computer board suppliers a common, flexible, and rapid method of creating system initialization firmware for BIOS-based PCs, open source platforms, real-time OSs (RTOS), or custom-designed platforms.  For this task the Intel Firmware Support Package is a pretty useful tool, but it has some surprising benefits for the military systems integrator that might not be immediately obvious.


I spoke with Jeff Porter, Director of Marketing at Extreme Engineering Solutions (X-ES) about how they use Intel Firmware Support Package in their latest Intel-based products.  Jeff told me that while they used the Intel Firmware Support Package for its intended task of generating a boot loader for their latest Intel-based products such as the 4th generation Intel® Core™ i7 processor-based XPedite7570 and XCalibur4530. They realized that it could also be a useful tool for their MilAero customers. “MilAero customers have struggled with the limitations of BIOS-based boot loaders such as long boot times, expensive security reviews, and the inability to easily customize the boot process.  Intel Firmware Support Package with open-source boot loaders help to change that”.


The BIOS or boot loader firmware is typically the first code that runs when a computer is powered on. It performs system initialization and loads the operating system in preparation for running the application. In a combat situation seconds count, so for embedded military systems there is a strong desire to minimize the time between power-on and an operating system. Intel Firmware Support Package gives the system integrator the power to tailor their boot firmware by including only those initialization functions that are absolutely necessary for their application, and thus minimizing boot times.


Figure 1: Intel® Firmware Support Package enables the rapid and easy generation of custom boot firmware.  This enables MilAero system integrators to customize their boot firmware for fastboot and increased security.


Military system integrators naturally have strong security requirements. Of all the various layers of software in a system, the BIOS, boot loader, and other firmware tend to generate the most concern.  Normally the source codes for these lower-level softwares are difficult and expensive for the integrator to acquire and are of uncertain pedigree with respect to their development.  The only option for the integrator has been to enter into extended contracts with the BIOS vendors to gain access to the firmware source files and performing a detailed code review (a very expensive and time-consuming exercise).


With the availability of Intel Firmware Support Package and open source projects such as the coreboot boot loader and the U-Boot or SeaBIOS packages, the embedded military system integrator can now easily spin their own boot firmware.  They have complete access to the CPU, memory controller, and chipset functions initialization source files, as well as the coreboot sources.  A security review of the source codes is still needed, but now they are only reviewing those functions that they intend to integrate into their system.  This results in better code traceability, lower costs to the integrator, and removes the hassle of having to enter into an extended support contract with the BIOS vendor.  It also has the benefit of working with either Linux or VxWorks – both of which are very common OS platforms for MilAero systems.


Jeff Porter says that they already have customers who are benefiting from using Intel Firmware Support Package to generate their own boot firmware.  Only time will tell how much of a benefit this will be to the MilAero system integrator. Suffice to say that Intel Firmware Support Package is an important new tool in the system integrators arsenal.


Learn More

Contact featured members:

Solutions in this blog:

Related topics:


Extreme Engineering Solutions is a General member of the Intel® Internet of Things Solutions Alliance.

Mark Littlefield

Roving Reporter, Intel® Internet of Things Solutions Alliance

OpenSystems Media®, by special arrangement with the Intel® Internet of Things Solutions Alliance

Since the early 1990’s the COTS High Performance Embedded Computing (HPEC) world has been dominated by processors in the sub-25 watt range.  Digital signal processors or processors with special DSP-like processing elements like the Intel® i860were the typical choice of system engineers.  They offered optimal megaflops-per-watt, which is generally considered the critical unit of measure for an HPEC system processor.  Heat dissipation is also an issue for HPEC systems, so a lower power target is always a benefit.


Over the last five years this pattern has changed with the introduction of FPGAs and graphics processors (GPUs) into the mix.  These components often broke the 25w limit normally imposed by board designers, but brought a huge jump in processing power over available microprocessors or digital signal processors (DSPs) with similar power consumption, giving them a vastly superior megaflops-per-watt over their more traditional competition.


The downside of both the earlier DSP/DSP-like processors and the later FPGA/GPU options is ease of development.  Applications developed on traditional HPC supercomputers (High Performance Computing, as opposed to HPEC) often had to be redesigned and rewritten to run on these HPEC platforms, and couldn’t use many of the tools available to the HPC community. This formed a costly disconnect between the scientists developing algorithms and applications, and the engineers tasked with developing deployable systems.


A recent development by Intel has the potential to change that.  At first glance the Intel® Xeon® processor E5-2400/2600 v2 family’s 50W to 115W power consumption would appear to high to be useful for an HPEC system.  A deeper look, however, uncovers an architecture and feature set that has so far convinced suppliers like Mercury Systems, Trenton, and ADLINK Technology that this processor is a compelling platform for HPEC applications.


Why Intel® Xeon® Processor E5-2400/2600 v2 for HPEC?


If we look at the basic feature set for the Intel Xeon processor E5-2400/2600 v2 we see the following features that contribute to HPEC performance:


  • Up to 10 cores (each capable of running two threads) ranging from 1.9 to 2.8 GHz (although clock rates higher than 1.9 GHz may consume too much power to be useful for an HPEC system).
  • Intel® Advanced Vector Extensions (Intel® AVX), a 256-bit vector SIMD engine for each core.
  • Large, 25 MB cache shared between the cores
  • Three or four DDR3 memory channels of DDR3-1866, providing up to 14.9 GB/s per channel (59.7 GB/s raw memory bandwidth)
  • Two QuickPath Interconnect  (QPI) links to a second processing node, each providing 8 GT/s (giga-transfers – 32 GB/s) or a total of 64 GB/s of bandwidth between processing nodes.
  • Up to 40 PCI Express Gen 3.0 lanes, although for HPEC applications these would most likely be configured as dual x16 interfaces, each giving up to 16 GT/s (approximately 15 MB/sec effective bandwidth).


In addition, the Intel Xeon processor E5-2400/2600 v2 family chipset includes support functions such as an integrated Gigabit Ethernet controller, USB and SATA ports, and an additional 8 lanes of PCIe Gen 2.0.


Figure 1:  Intel® Xeon® processor E5-2600 v2 two-processor architecture block diagram.

What These Features Mean for HPEC Systems


A classical application of an HPEC system is to perform large, two-dimensional Fast-Fourier Transforms (FFT) or its inverse, the iFFT.  This computation (along with many other digital signal processing algorithms) depends heavily on a multiply- accumulate operation, the so-called “butterfly” operation.  Given this, the Intel Xeon processor E5-2400/2600's AVX extensions are critical to raw calculation performance.


Raw calculation performance is only a part of the story, however.  Calculation latency minimization is the real aim of HPEC, and a multi-mega point (1Kx1K or greater) 2D FFT takes a lot of calculations. Therefore, the only way to minimize calculation latency is to break the problem up across multiple processors. The problem with performing a 2D FFT/iFFT across multiple processing cores is that a distributed matrix transform (or, “corner turn” as it’s known in DSP circles) is needed half way through the calculation.  This requires a great deal of data movement between processors and core caches, which means that calculations essentially halt until the data movement is completed.  Several features of the E5 V2 family lend themselves to optimizing this operation, including:


  • Large last-level cache, which minimizes memory reads or flushes.
  • Four independent banks of high-speed DDR3 memory, which when managed appropriately and combined with the last-level cache, minimizes memory overheads.
  • Dual QPI channels, giving each core direct high-speed access to the corresponding processor’s memories.
  • Dual x16 Gen3 PCIe, to maximize data transfer performance between boards.


Looking at the practical limits of a VPX, ATCA, or similar form factor based HPEC system we can set our power consumption limits at 160-200W/slot.  Applying that to the natural two-processor architecture of the Intel Xeon processor E5-2400/2600 v2 we see that the Intel procdessor E5-2648L is a natural candidate (although the Intel Xeon processor E5-2628L or the Intel Xeon processor E5-2468L may be alternatives if cost is a driving factor).  An Intel Xeon E5-2648L 2-processor system provides:

  • 20 cores at 1.9 GHz on a shared high-speed bus
  • Eight DDR3 memory channels with 50 MB of last-level cache
  • Four channels of 16-lane PCIe for inter-board communications


We can immediately see that the Intel Xeon processor E5-2400/2600 v2 architecture provides an effective megaflops per watt calculation density with extremely fast memory and inter-core communications.  However, GPUs, FPGAs, and DSPs also provide similar performance numbers.  What, then, makes the Intel Xeon processor E5-2400/2600 v2 a compelling choice for HPEC systems over these alternatives?


Additional Benefits


We mentioned the downside of using DSPs, FPGAs, or GPUs above.  This problem is largely avoided with Intel Xeon processor E5-2400/2600 v2-based system. John Bratton, Product Marketing Manager at Mercury Systems says that the ability to leverage traditional HPC tools and codes is a specific goal of their Intel Xeon processor E5-2400/2600 v2-based HDS6602 product – essentially “moving HPC to HPEC”.  By using Intel Xeon processor E5-2400/2600 v2based platforms, system integrators can benefit from faster time to deployment by leveraging SMP single OSs like Linux and other latency-reduction HPC tools.  It also directly address the problem of “model year upgrades” by enabling better performance through future new platform integration with little or no software porting effort.


Lastly, this aligns military HPEC systems with Telco and other commercial embedded multicomputer markets that have already embraced Intel Xeon processor-based platforms.   Suppliers such as Trenton with their BXT7059 SBC and ADLINK with their aTCA-6250 blade serve these markets, and are now interesting solutions for the HPEC market as well. This has the potential to expand the supplier base for military embedded systems and to drive down system lifecycle costs.

Xeon E5V2 Products.png

Figure 2: Three embedded solutions all leveraging the power of the Intel® Xeon® processor E5-2400/2600 v2 family of processors, including the ADLINK aTCA-2650, the Mercury Systems HDS6602, and Trenton Systems BXT7059.  All three share the two-processor architecture that maximizes the processing and communications performance of the Intel® Xeon® processor E5-2400/2600 v2 family.


The Intel Xeon processor E5-2400/2600 v2 family is proving to mark a paradigm shift in military high-performance embedded computing. By integrating 10’s of cores in a tightly-connected high-performance communications fabric, with multiple high-speed memories, large caches, fat high-speed I/O pipes, and a friendly and widely-support development environment, these components warrant serious consideration by system integrators and are undoubtedly destined to be widely deployed.


Learn More

Contact featured members:


Solutions in this blog:

Related topics:


ADLINK is an Associate member of the Intel® Internet of Things Solutions Alliance.

Trenton Systems, Inc. is an Affiliate member of the Alliance.

Mercury Systems Inc. is a General member of the Alliance.

Mark Littlefield

Roving Reporter, Intel® Internet of Things Solutions Alliance

OpenSystems Media®, by special arrangement with the Intel® Internet of Things Solutions Alliance

Modern electronic systems have had a revolutionary effect on the ways that the US Army conducts its missions.  They give the modern warfighter a degree of situational awareness and fire control orders of magnitude better than previous generations, allowing the warfighter to carry out his or her mission more quickly, reliably, with less risk of collateral damage, and with lower risk to the warfighter.


However, the Army has a problem.  The proliferation of these systems over the past 25-30 years has meant that vehicle crew cabins are now cluttered with various types of electronics such as radios and data systems, navigation, image and signal surveillance, shot detection, rocket defense, and fire control systems.  Each of these systems has their own computing hardware, sensors, displays, and keyboards or other operator input devices, and almost none share information with the others.  The result is a disordered and crowded workspace, and the manual coordination of these systems means an increased workload on the warfighter.


Taking a queue from the commercial computing industry where networking and coordination between personal computers, mobile computing, and “the cloud” is the norm, the Army set out to address this problem.  In January 2009 the Army’s Tank Automotive Research, Development, and Engineering Center (TARDEC) formed the Vehicle Electronics Architecture (VEA) technical area to study this problem.  About this same time, the Army’s Program Executive Office Command, Control, and Communications – Tactical (PEO C3T) started the Vehicle Integration for C4ISR/EW inTerOpeRabilitY (VICTORY) architecture project to improve how C4ISR subsystems are integrated into ground vehicles.  In May 2010 these two groups, along with the Army’s Research Development, and Engineering Command (RDECOM) and a number of other Army PEO’s, met to form the working groups of the VICTORY Standards Body.

VICTORY Figure 1 raw.png

Since then the VICTORY Standards Body has generated an impressive amount of technical material including architecture and standard specifications, a reference design and reference library, and a preliminary compliance test suite.  The group has also performed significant industry outreach, bringing prime contractors and COTS suppliers into the standards process and drafting specification language that can be easily incorporated into RFIs and RFPs.


I recently spoke with three leaders in the COTS VICTORY Architecture activities about their views on the VICTORY Architecture, their companies’ approach to VICTORY, and how Intel technologies are addressing their needs.  Here’s what I learned:


What is the VICTORY Architecture?

Jedynak_crop.jpgDavid Jedynak, Chief Technology Officer at Curtiss-Wright Controls Defense Solutions: VICTORY is a standard that enables plug-and-play for military vehicle systems, like a USB mouse for a modern desktop or laptop.  It also enables interoperability between systems. Currently vehicle electronic systems (vetronics) are “stovepiped”, with each system having its own display, keyboard, and so on.  In addition, there is no sharing of information or sensors such as GPS between the systems.  A networked information flow with standardized messaging and a shared timebase are the key to VICTORY.


David Pepper, Product Specialist at GE Intelligent Platforms: The VICTORY architecture solves the interoperability problem for in-vehicle systems.  Separate boxes for different functions can now combine capabilities via networks with a common set of interfaces.


Jeff_Porter_300dpi_2.jpg Jeff Porter, Director of Marketing and Product Development at Extreme Engineering Solutions: VICTORY is about networking, with a focus on switch management, routers, and compatibility.


What does the VICTORY Architecture bring to the warfighter?


DJ/CW: VICTORY brings a more modern, networked approach to vetronics.  It reduces SWaP (Space, Weight, and Power) and cost by consolidating functions such as GPS.


JP/XES: Easier and cheaper upgrades through defined compatibility.


DP/GE: In short, it brings improved SWaP.  It also promises fewer operator interfaces.  It’s really all about more and better system integration.


What does VICTORY mean for your company?  Specifically, how important is it to your strategy?


JP/XES: VICTORY is driving our product planning today.  We are beginning to see interest, so it is important that we are compliant with our products going forward.  We expect to see it more with both new vehicle and legacy platforms.


DJ/CW: VICTORY lends itself to COTS-based solutions, so it is particularly important to Curtiss-Wright.  In addition, it allows more hardware abstraction and gives the integrator the ability to choose hardware sized right to fit the application.


DP/GE: The services drive the VICTORY architecture, but GE involvement is important for driving it into our product planning.  GE needs to make sure that our products are compliant. We will see this flow down from the primes and we must be ready.


What are the challenges?


DJ/CW: We need to be sure that we are designing hardware to be “VICTORY Ready”.  In addition, existing vehicles need to be upgraded to support VICTORY, which means that there is a “chicken and the egg” problem for VICTORY deployment.  Lastly, the government acquisition chain hasn’t yet fully embraced VICTORY, so there have been limited calls for it in RFIs and RFPs to date.


DP/GE: The standard is still evolving.  Therefore, GE needs to stay engaged.  We expect that it will take another year or more for VICTORY to mature.  Libraries based on VICTORY are under development, and a reference library has already been released.  A test suite to show compliance is still needed, however.


What products or features does Intel provide to help enable VICTORY?


DP/GE:  Intel network controllers and switches with integrated MAC/PHY are particularly important to us, such as the Intel Ethernet Switch FM4000.


JP/XES:  For us it’s about networking, supporting the hardware, protocol, and management capabilities in the specification.


DJ/CW:  Intel products that support the Precision Time Protocol (IEEE 1588) are key to the success of the VICTORY Architecture.  Also, multi-level security (MLS) continues to be a concern for military systems, so hardware-based Intel® Virtualization Technology (Intel® VT) like that found in the latest Intel® Core™ i7 processors are important for establishing separate secure “enclaves”.


Learn More

Contact Featured Alliance Members:


Related topics:

·        Interoperability - Top Picks (blogs, white papers, and more)

·        Military, Aerospace, Government - Top Picks (blogs, white papers, and more)


GE Intelligent Platforms is an Associate member of the Intel® Intelligent Systems Alliance. Curtiss-Wright Controls Defense Solutions and Extreme Engineering Solutions are General members of the Alliance.


Mark Littlefield

Roving Reporter, Intel® Intelligent Systems Alliance

Filter Blog

By date: By tag: