Editor’s note: While many embedded design considerations depend on the target application, some requirements are inevitable: greater performance, lower costs, and increasingly faster time to market. Thanks to major advancements in process technology, FPGAs address all of these design needs by offering substantial parallel processing capabilities, as well as quick-fix infield upgradability. For a comprehensive overview of how FPGA technology can help achieve embedded design goals, we interviewed executives from the leading FPGA companies and collected excerpts from their responses in this virtual panel discussion.

Figure 1: Executive panelists (click graphic to zoom)

ECD: With higher power requirements and recurring costs than custom logic or ASICs, which projects are best suited for FPGA technology?

BURICH: FPGAs have benefited significantly from Moore’s Law, and as a result have been able to stay at the bleeding edge of process technology while at the same time considerably reducing power consumption and development costs. As the costs of advanced process technologies rise (about $60 million for an ASIC at 40 nm), it gets harder to justify the upfront R&D costs. Today, we see a shrinking number of applications that can justify a leading-edge ASIC – mostly restricted to cell phones, PDAs, video games, and other high-volume applications. Those who can’t justify such an upfront investment seek to use trailing-edge process technologies.

In contrast, FPGAs can afford to use the latest process node and take advantage of Moore’s Law because there is a much wider array of applications that FPGAs can target. Today’s leading-edge FPGAs are 2-3 process nodes ahead of where most ASICs are, giving users the most advanced process technology available plus all the accompanying benefits at an overall lower cost. Development costs of leading-edge FPGAs are dramatically reduced because FPGA vendors can aggregate development costs across thousands of designs and customers. FPGAs are ideally suited for industrial, communications, automotive, military, medical, aerospace, and other designs with sub 1 million volumes or where a high degree of flexibility is required.

GETMAN: You have to be careful not to take an overly simplistic view when looking at power and cost and comparing different components like ASICs, ASSPs, FPGAs, and new hybrid products like Extensible Processing Platforms (EPPs). The comparison cannot just be at the device level; it also requires analysis at the system level and overall project level.

Design engineers must first answer some tough questions concerning costs, tool availability and effectiveness, production volume, time to market, and how best to present this information to management to gain support throughout the design process.

It’s interesting to compare these technologies, but in the end, the application is the final differentiator. A list of design objectives in order of importance, including cost (both development – nonrecurring engineering, and production – recurring unit cost), die size, time to market, tools, performance, and IP requirements must first be created. Then ask which technology best meets those objectives.

That analysis cannot just stay at the device level, where ASSPs and ASICs have an advantage with regard to both power and cost. For ASICs, the upfront cost means that only very high-volume applications can efficiently use an ASIC. Another trend is for companies to develop “kitchen sink ASICs,” where the design requirements for many different end products are the same, thus a single ASIC targeting multiple applications can be developed. However, this creates a problem with design complexity and project risks. Therefore, many customers are moving away from this approach after experiencing product delays and receiving products that, in the end, do not serve anyone’s needs perfectly. The other disadvantages that kitchen sink ASICs bring are that the silicon area is “inflated” to accommodate all the target applications, and therefore is less cost- and power-efficient.

We have always told our customers that if you have an ASSP that does exactly what you want and do not need or want to differentiate your product through hardware functions, then maybe that ASSP is the right choice for you. Most designs, however, can benefit from a flexible, programmable device that targets their unique applications and differentiates their products from the competition.

To accomplish that, many ASSP users add an FPGA next to their ASSP. While this offers a certain level of flexibility, it can also present some performance and power consumption challenges, stemming from the interface between the ASSP and the FPGA. This is why in the past few years, we have seen a push for fully integrated FPGA solutions, as well as FPGA vendors starting to offer hybrid solutions like an EPP (see Figure 2).

Figure 2: An Extensible Processing Platform (EPP) combines a high-performance dual-core ARM processor with standard peripherals and programmable logic. (click graphic to zoom by 1.8x)

Over time, FPGAs have begun taking commonly used blocks such as DSP multipliers, small block RAM memories, and even high-speed serial I/O to offer the best balance of features and flexibility. The Zynq-7000 EPP family uses standard ASIC techniques to harden close to 11 million ASIC gates in the processing subsystem. This type of architecture swings the financial and technical bar around total cost of ownership, performance, and power radically away from traditional ASICs.

Massive parallel processing capabilities are another key benefit of FPGA technology, allowing designers to reach a level of performance not achievable with ASSP products. Additionally, using FPGAs within an EPP greatly reduces the risks involved when designing with ASICSs and ASSPs, as these devices cannot accommodate late design changes and do not provide the flexibility of infield upgrades. FPGAs offer the ultimate system integration platform to meet the growing need for programmable systems that cut development cycles, enable adoption to changing standards, and extend product lifetimes through field upgradability.

This segues perfectly to reducing time to market, a major advantage for any company’s product. FPGA technology allows our customers to move to market quickly, often in a matter of weeks, while drastically reducing their R&D costs. We offer design engineers a blank device that can be configured and reconfigured on-the-fly to implement any logic function that can be performed by an application-specific device. FPGA technology allows our customers to make changes to their designs very late in the design cycle. Even after the end product has been completed and shipped, they can extend its useful life by reprogramming the FPGA.

Innovations in FPGA technology have reduced the gap of power per device, making FPGAs much more competitive from a power standpoint. The battle to deliver maximum performance with minimum power expenditure is center stage in the evolution of the FPGA. Power conservation affects every budget, whether technological or financial. Product acceptability, reliability, and profitability depend as much or more on power efficiency as they do on performance, regardless of the type of project.

However, the key element of power savings will come from integration and reduced power consumption due to the chip-to-chip interface, which again, must be analyzed at the system level and not just at the chip level.

Increased system performance means new process technologies, massive parallel processing capability, advances in memory interfaces, high-speed transceivers (up to 28 Gbps), and no bottlenecks due to chip-to-chip interfaces. Decreasing power again relates to process technology, and in our case, this means using TSMC’s high-performance, low-power 28 nm process (a unified architecture across all of our 7 series FPGAs), other technology innovations, and burning no power to do chip-to-chip interfaces in a single device, as well as using fewer power supplies to reduce power consumption on the boards. Cost reduction is based on the use of a single device, which means there are no upfront costs and fewer components used on the board, resulting in a smaller bill of materials and a simpler design.

RILEY: The traditional trade-offs between FPGAs and ASICs/custom devices are still in effect. For a specific application, ASICs are lower power and lower cost, but they take much longer to develop and require a large upfront investment. What’s changing are the time-to-market requirements and useful market life for many projects.

Communications and wireless infrastructure developments are under tremendous pressure to get to market, driving engineers to consider process technologies that are reprogrammable and available today. In many cases, this is an FPGA. In the past few years, companies such as Lattice Semiconductor and SiliconBlue Technologies have been developing FPGAs that have solid capabilities and are priced well under $1. In fast-moving, cost-sensitive markets like consumer mobile, this type of solution is often the only way to add functionality in such a short time.

ECD: How can FPGA technology help embedded design teams deal with reduced budgets and increased system complexity?

GETMAN: While system complexity increases and the reduction of system design budgets becomes more of a reality, embedded system designers are jumping on the FPGA technology bandwagon to shorten design cycles, battle obsolescence, and simplify product updates. Using the constantly growing number of integrated FPGA development tools, reusable logic elements, and off-the-shelf modules, designers are creating new and innovative embedded systems that can be easily reconfigured for updates and changes in requirements with only a minimum impact on engineering and manufacturing.

FPGA designs combine multiple components into a single package that reduces component count, board size, and manufacturing complexity. Processors, memory, custom logic, and many of the peripherals in a typical embedded project are now in the FPGA. Today’s FPGA architecture has grown into billions of logic blocks (equivalent to gates), and with programmable interconnection flexibility designers can easily create hardware functions that exactly match the needs of a specific embedded application.

Drop-in IP cores from device vendors, third-party suppliers, and the open-source community ease FPGA set-up. The standardization of an IP interface (we use the AMBA 4 AXI standard) also greatly reduces design complexity when integrating functions into a single device. Furthermore, fueling a comprehensive ecosystem of hardware design tools, as well as software design tools and operating systems, is yet another key element of reducing design complexity.

Designers can segment FPGA-based signal processing algorithms into parallel computing structures to boost performance. High-level synthesis tools such as AutoESL can help simplify FPGA design and enable companies and developers not familiar with FPGAs or even hardware design to reap the inherent benefits of FPGA technology.

By utilizing a broad set of tools, the embedded designer’s tool bag for enabling FPGA technology has become increasingly mainstream. FPGA vendors are putting significant time and money into their development tools to improve the turnaround time, which will permit more iterations while reducing time to market and saving engineering efforts. The integration of many system elements into a single device reduces design complexity, as there are fewer chip-to-chip interfaces, as well as fewer performance bottlenecks.

RILEY: FPGAs are often used as bridging or coprocessing solutions. This allows embedded engineers to build systems out of the products they have. Can’t connect two dissimilar processors? No problem. FPGAs support a wide range of I/O types. Can’t handle the processing load? No problem. FPGAs can be configured to offload key functions.

FPGAs help get system products to market quickly, and the price and power of FPGA solutions has been dropping at a breakneck pace the past 10 years. FPGAs are used today in smart phones, tablets, laptops, handheld GPS devices, and many other platforms that were once the sole domain of custom logic.

BURICH: Designers today are challenged to get many different systems to market in shorter and shorter periods of time. By enabling easy customization for different features, price points, and evolving standards, FPGAs enable engineers to design a common platform and quickly spin off varying systems.

One of the most disruptive aspects of embedded design is adopting a new architecture to meet changing requirements. The industrial, medical, and military segments, for example, are also very concerned about product longevity and avoiding device obsolescence. By designing with FPGAs, customers can make incremental changes to a common design to adapt to changing market needs or industry specifications. Having a common tool flow with extensive design reuse addresses budget and time constraints.

New System-on-Chip (SoC) FPGAs featuring hard ARM processor subsystems also help embedded design teams address reduced budgets (see Figure 3). Today’s leading-edge FPGAs are targeting 28 nm process technology, which relatively few commercial CPUs or ASSPs use. A monolithic SoC FPGA system maximizes power efficiency and software partitioning flexibility. SoC FPGAs allow hundreds of data signals to connect different functional areas, thus enabling 100 Gbps or greater bandwidth with nanosecond-level latencies, representing orders of magnitude better performance and latency than discrete implementations. Furthermore, monolithic integration permits memory controllers to be shared, allowing high-bandwidth memory access for hardware accelerators. A monolithic SoC FPGA implementation enables embedded design teams to increase system performance while lowering system costs and reducing power versus a two-chip solution.

Figure 3: Today’s SoC FPGAs combine a hard ARM processor subsystem with the fabric of a 28 nm FPGA. (click graphic to zoom by 1.9x)

ECD: One of the biggest obstacles to adopting FPGA technology has been the steep learning curve associated with development tools. How has this changed?

BURICH: This depends on the designer’s background. Those familiar with ASICs can quickly adapt to FPGA design flows and save time through the benefits of quicker verification in real silicon. Those who are not familiar with Real-Time Logic (RTL) will have a steeper learning curve. This is being addressed in two areas. The first is system-level design tools such as Altera’s Qsys, which enables designers to quickly assemble different design blocks using a higher-level graphic block environment. The second is automated RTL development from C language source. While this approach has been tried for many years, it is now coming of age for embedded developers with standards such as OpenCL. OpenCL also addresses the increasing challenge of designing multicore systems. Altera recently announced a program for evaluating FPGA-based OpenCL implementations.

GETMAN: Developing FPGA solutions can be complex, requiring the appropriate software tools. While each chip technology requires specific design tools, FPGA users are shielded from concerns of manufacturing yield and submicron issues by the nature of FPGA design flow, which brings ease-of-use, cost, and time-to-market benefits. FPGAs arrive fully tested and physically functional; the FPGA supplier handles physical design, verification, and characterization. Xilinx offers integrated design and debug tools for logic, DSP, and embedded processing, plus interfaces to third-party tools. FPGA design tools have improved dramatically, particularly [those] tools that apply high-level languages or interfaces to develop applications, such as MATLAB/Simulink from MathWorks.

Depending on the provider, software to program FPGAs varies in content and value-add features like compilation and editing tools. Very high-speed Hardware Description Language (VHDL) is the most common development language used. It allows FPGAs to be programmed via an easy-to-use graphical development environment. Additionally, FPGA vendors who provide tools such as development boards, support, and reference designs simplify the FPGA design process.

Conversely, there are longer design and verification cycles for ASICs, with a high likelihood of design re-spins and associated penalties. Plus, costly verification tools, training, and resources are required.

FPGA vendors who continue investing in software development tools and IP will enable more complex systems to be designed while carrying their silicon platform forward and promoting growth. The challenges going forward have not changed. These challenges continue to be reducing power, providing more capability at a lower cost, and further simplifying the programming. As progress is made on all of these fronts, the market share for FPGAs is increasing over ASIC/ASSP providers.

RILEY: The learning curve for FPGA design tools depends on where you are coming from. If you are an ASIC designer, the FPGA design tools will seem familiar. A design flow that includes HDL design entry, simulation, synthesis, and place and route is similar to an ASIC flow. For a software engineer who is used to programming in C/C++, the FPGA design flow will be new and require a learning curve.

Some vendors have claimed that you can write your code in C and their tools will automatically convert it to HDL. In my experience, this process still requires much human engineering to achieve the system throughput goal that drove the need to move beyond the confines of the microprocessor. There are well-established methodologies for partitioning a design between software and dedicated hardware. These still result in the best cost and performance, and FPGAs allow designers to experiment with different partitioning. Over the years, some FPGAs have included integrated processors, but they have not been successful. One reason for this is the lack of flexibility.

The world of microprocessors is vast. You can find any price, performance, or power point you desire from multiple vendors. Once you integrate the processor into the FPGA, your options become limited very quickly.

ECD: What types of IP core libraries do you offer to shorten the embedded design process?

RILEY: Lattice offers a wide range of IP cores, reference designs, and evaluation boards for PCI Express, Serial Rapid I/O, XAUI, Finite Impulse Response (FIR) filtering, Fast Fourier Transforms (FFTs), image and video scaling, MIPI interfaces, and more. Lattice focuses on the mid-range and low-density segments within the FPGA market. This means we concentrate on delivering high-end capabilities such as DDR3 memory interfaces and advanced filtering in low-cost, low-power FPGA platforms.

Lattice offers IP cores through a novel tool called IPExpress, which allows customers to change high-level parameters and generate new IP structures tuned to their feature, size, and performance requirements. Lattice provides many reference designs for free at our website. We also work closely with our customers to generate custom designs to meet their needs.

BURICH: IP libraries are important, and we offer a wide range of cores from memory controllers to embedded peripherals to high-speed communications interfaces. One of the most popular is our Video and Image Processing (VIP) Suite and our Nios II embedded processor IP. We also have a partner ecosystem that offers IP cores tailored to meet specific application requirements.

Just as important as the IP offering is the interconnect logic that ties the IP cores together into a coherent system. Altera offers a system integration tool (SOPC Builder) that automatically generates the logic that handles seemingly trivial yet critically important tasks of bus width adaptation, bus arbitration, bursting, interrupts, and more. We connect memory-mapped and streaming interfaces seamlessly and support high-performance bus standards like ARM AXI, as well as our lightweight, open Avalon interface standards. With the introduction of Qsys, we now generate a Network-on-Chip architecture offering even higher levels of performance and flexibility. Designers can not only assemble IP cores into a custom system, they can also create custom subsystems that can be shared internally to exploit the FPGA design reuse advantage.

GETMAN: Xilinx offers nearly 100 different embedded processing peripheral IP cores in categories including Processor IP Cores, Interface/Bus/Bridge IP, Peripheral IP, Communications IP, Infrastructure IP, Memory Controller IP, and Debug IP. These cores are included with the ISE Design Suite: Embedded Edition Development Kit and work directly in our Platform Studio, which supports MicroBlaze and PowerPC for PLB-based cores and MicroBlaze for AXI-based cores.

ECD: Which industry standards do you support to provide customers off-the-shelf, reconfigurable designs?

GETMAN: We see two aspects with regard to supporting industry standards, one at the external level and one at the internal level. At the external level, take the FPGA Mezzanine Card (FMC) defined in VITA 57 as an example. By using the reconfigurable I/O of FPGAs, design engineers can easily change a transceiver protocol or an I/O standard and route it through a different card connected to the FMC connector on our boards to create a new application/customer. Examples of internal standards that enable quick configuration/reconfiguration are AMBA 4 AXI, IP-XACT, and the proposed IEEE standard for IP Quality (QIP).

We support many interface standards for most market segments, including wireless communications, aerospace and defense, intelligent video, automotive, instrumentation, and medical imaging, which eases the connection to other systems. Having a comprehensive IP offering from Xilinx and its partners enables designers to quickly reconfigure their designs for applications or products.

RILEY: Lattice supports a wide range of hardware standards to help customers evaluate our silicon, design tools, and IP cores. Many of these evaluation boards are available for under $199, which allows customers of all sizes to experiment with Lattice products. Two standards that are popular with embedded designers are PCI Express and the Advanced Mezzanine Card. The AMC provides an FMC expansion connector, a USB-B connection to UART for runtime control, an RJ-45 interface to 10/100/1000 Ethernet, and an SFP transceiver module cage and connection.

BURICH: From the IP interconnect perspective, we support ARM’s AMBA AXI bus standard, as well as our own open Avalon bus standards (memory-mapped and streaming). Our Qsys system integration tool supports both AXI and Avalon, and the architecture of the tool is such that we can add other interconnect standards easily as needed.

From the IP interface standard perspective, we and our partners offer a wide range of IP cores that can be assembled into a custom system quickly with Qsys. Altera offers a wide variety of IP blocks of differing size and complexity, from the basic arithmetic blocks to transceivers, memory controllers, microprocessors, signal processing, and protocol interfaces. Altera and its third-party IP partners offer a broad portfolio of off-the-shelf, configurable IP cores optimized for Altera devices. Licensed and unlicensed IP is delivered and installed with our Quartus II design software.

ECD: Marketing materials for new processors with Advanced Vector Extensions (AVX) suggest replacing external FPGAs with code. Will this new architecture affect the FPGA industry?

RILEY: AVX is an extension of the x86 instruction set targeted at improving performance, specifically in floating-point designs. Processors with AVX can work together with FPGAs to handle tasks such as bridging a dual-sensor interface to a new processor (see Figure 4). These extensions will allow embedded designers to do more with their x86 architectures; however, the performance gulf between a processor and an FPGA is still very large. Benchmark applications such as Finite Impulse Response (FIR) filtering, Fast Fourier Transforms (FFTs), and 2D image filtering are still many times faster on FPGAs than microprocessors. Also, FPGAs are superior for implementing general-purpose logic and bridging to dissimilar devices. So AVX will be a big help to many embedded designers, but it won’t obviate the need for FPGAs in embedded designs.

Figure 4: Lattice Semiconductor’s MachXO2 FPGA can be implemented as a high-speed CMOS sensor interface. (click graphic to zoom by 1.9x)

BURICH: Custom hardware has always outperformed software. The trade-offs of off-the-shelf hardware extensions are:

1. They might not be optimal for a broad range of applications; only custom, application-specific hardware can deliver the best performance. AVX offers benefits to the PC and tablet industries, but FPGAs already come with strong parallel processing capabilities and are the better fit for embedded markets. One-size-fits-all acceleration incurs the cost of answering a wide range of needs, resulting in inherent inefficiencies.

Off-the-shelf hardware extensions don’t lend themselves to establishing a competitive advantage because competitors have access to the very same hardware and software. Custom hardware can create a competitive differentiator and help developers create a product that outperforms the competition in both performance and revenue generation.

GETMAN: These types of specialized extensions are not new trends to the industry. As an example, MMX was introduced in the mid ’90s on Intel Pentium processors to improve multimedia processing. The ARM architecture is also enhanced with NEON extensions that serve a similar purpose.

In a design where an FPGA is used to perform simple accelerator functions for the main processor, the extra gain in performance from AVX will remove the need for some FPGAs. However, FPGAs are used for other functions beyond just simple accelerators, such as adding peripherals to the main processor, and the AVX architecture cannot address this need covered by FPGAs.

With the continual need for increased system performance, fixed defined instructions might not perfectly address a great deal of proprietary algorithm processing. This results in more clock cycles per function, yielding not only lower performance, but also higher power. This makes the massive parallel approach provided by FPGA architecture well-suited for hardware acceleration, thus enabling customers to continue achieving higher system performance. Therefore, the answer on industry effect is both yes and no.

In addition, FPGA companies have introduced new hybrid architectures (such as the Zynq-7000) that combine application-class processors and programmable logic. These new architectures offer the capability to add hardware accelerators in the programmable logic and have it controlled by the processor in a similar way as AVX. The massive parallel processing capabilities of programmable logic available in these hybrid devices enable performance beyond what AVX instructions could bring to a processor.

Misha Burich is the senior VP of R&D at Altera.

Lawrence Getman is the VP of Processing Platforms at Xilinx. Prior to this role, Lawrence was in charge of corporate development at Xilinx. Before joining Xilinx, he worked as the VP of Business Development at Triscend Corporation and held a variety of marketing and sales roles. Lawrence has a BSEE from Rochester Institute of Technology and an MBA from San Jose State University.

Sean Riley is Corporate VP of the Infrastructure Business Group at Lattice Semiconductor.

Altera
Linkedin: www.linkedin.com/company/altera
Facebook: www.fb.com/alteracorp
Twitter: @alteracorp
www.altera.com

Xilinx
Linkedin: www.linkedin.com/company/xilinx
Facebook: www.fb.com/XilinxInc
Twitter: @XilinxInc
www.xilinx.com

Lattice Semiconductor
Linkedin: www.linkedin.com/company/lattice-semiconductor
Facebook: www.fb.com/latticesemi
Twitter: @latticesemi
www.latticesemi.com

Companies today are seeking to own more of the vertical design chain by bringing chip design in-house. If not done properly, this will create more problems than it solves. The key is to use a common high-level model of the hardware for software development and debugging that can also be taken into an automated hardware implementation flow. By developing hardware models in SystemC-based Transaction-Level Modeling (TLM), software teams can debug against virtual prototypes long before a hardware prototype is available.

The consumer and wireless communications markets are more competitive than ever. The ongoing battle between aggregation and disaggregation of companies is in full swing. One example of aggregation is a decision to own more of the vertical design chain by bringing chip design in-house. This has helped companies like Apple differentiate by controlling more of the overall product design and thus not being limited by off-the-shelf chips that are available to everyone else.

While Apple has demonstrated the potential reward of vertical differentiation, this approach does pose significant risk, whether a company has experience designing chips or not. Specifically, how does the software team develop software that works with the hardware as shipped?

On the other side of the equation, complete disaggregation is enabled by software abstraction layers like Google’s Android operating system. It has somewhat democratized the design space, allowing all system companies to participate and differentiate using software. Android allows semiconductor vendors to participate equally by providing supporting hardware. Again, the way the software works with the hardware determines product success.

Traditional solutions to this problem do not work in today’s market. Companies used to be able to start software development based on specifications and wait for chip prototypes to be available for testing. That works if the software is very simple, independent of hardware, and has a straightforward specification, but not with today’s consumer electronics that require everything be connected.

Furthermore, waiting a long time to begin testing pushes the debug cycle out far too late in the schedule. Many companies addressed this in recent years by moving to standard off-the-shelf chips, but that approach limits the ability to differentiate. What if you want to add a power-saving sleep mode but there’s no way to shut down the chip?

In an aggregated scenario, companies are looking to differentiate not only in software and industrial design, but also in electronic hardware. Embarking on a chip design project poses its own risks; couple that with embedded software development, and overall project risks go up exponentially. Most companies are careful enough to spend ample time up front architecting the system, testing it, partitioning it into software and hardware, and specifying the behavior of both. But once each team begins designing, certain implementation assumptions are made, bugs are introduced, and features can be added.

The scenario is even worse in a disaggregated world, as the responsibility now spans across company borders. Companies from the systems and semiconductor world might decide to work together to optimize hardware/software interaction and create a chip optimized for system needs. Even if there are constant synchronization meetings, design changes will sneak in unbeknownst to the software team and might not be seen until the first time the software is run on the actual hardware. This cycles back to the problem of the hardware not being available soon enough. How do engineers solve this conundrum?

A golden model for prototyping

Virtual prototypes (or virtual platforms) of hardware that come in the form of software models give the software team a model of system hardware earlier in the process. This enables developers to begin testing on a model of the hardware specification. However, it is only a model of the specification. Most hardware design today starts with engineers reading and interpreting the specification, then writing low-level Register-Transfer Language (RTL) models in a hardware design language such as Verilog to begin the verification and implementation process. Due to the factors mentioned previously, hardware behavior will likely diverge from the specification.

The solution is to use a common “golden model” on which the software team can develop and with which the hardware team can begin their implementation. This is now possible with the availability of the Open SystemC Initiative (OSCI) Transaction-Level Modeling (TLM) 2.0 standard.

In short, SystemC is a class library that enables hardware design using C/C++ by modeling hardware data types and concurrency. Because hardware can now be modeled in C, that same model can be run by the software team. The TLM extensions are important because they abstract away all the signal-level protocol details the hardware needs to ensure that it communicates properly with the system bus. An excess of these details makes the model too slow for running the software. TLM abstracts those details to higher-level models that can be mapped to detailed hardware during high-level synthesis.

Resolutions to high-level synthesis limitations

High-level synthesis provides the automated link between the C model and the actual hardware that gets built. This removes the human factor of the hardware designers interpreting the specification and manually writing their own model to begin building the hardware. Until recently, this had rarely been used in practice because of some key limitations that have now been addressed:

• Quality of results: The first two generations of high-level synthesis were never able to produce hardware that met the same performance, power consumption, and size that could be achieved by manually writing RTL. Modern high-level synthesis technology has resolved this issue.
• Refinement methodology: The high-level virtual prototype for software development is described with SystemC TLM, but it still requires that the hardware team refine it by adding in hardware architecture details so that high-level synthesis can produce optimal hardware microarchitectures. These details are too low-level for software testing and would slow down its speed, but they are important for building efficient hardware. This methodology now exists and has been proven by early adopter customers.
• Verification: Until very recently, engineers lacked a mature methodology to verify the correctness of the hardware architecture in SystemC TLM and the rest of the hardware implementation flow. This is mainly because an automated path into implementation did not exist, so most verification was done at lower levels. Thus verification became the bottleneck in the hardware development schedule. Now that the automated path exists, verification methodology has been developed.

Hardware design teams are familiar with these traditional barriers to designing and verifying hardware using SystemC TLM. Most, however, are not aware that these barriers have been addressed. Those who are aware now enjoy a significant competitive advantage. They can describe their hardware much more efficiently, verify it more rapidly, and reuse it in derivative chips more easily.

Virtual platform in practice

A common model of the hardware is now available as part of a virtual platform much earlier so hardware/software interactions can be addressed sooner. This common model can be delivered as part of the bigger system in a virtual platform either within the company in an aggregated development scenario or across companies in a disaggregated world.

One example of the way this works in practice is captured in Figure 1, which illustrates the flow provided by the Cadence System Development Suite, an integrated set of hardware/software development platforms.

The system concept is first described as a SystemC TLM virtual prototype. In the Cadence flow, this virtual prototype is used by the Virtual System Platform to run the software on this hardware model. In parallel, the hardware design team will refine the TLM to add hardware architecture details for C-to-Silicon Compiler high-level synthesis, which is the beginning of the implementation process that will lead to silicon.

If bugs are uncovered during testing, the Virtual System Platform is integrated with the Incisive Verification Platform so that debug can happen on both software and hardware. This means that issues can be addressed at their source without cumbersome firmware patches. As the hardware implementation process progresses, more detailed RTL models become available to create hardware emulation models in the Verification Computing Platform or an FPGA prototype in the Rapid Prototyping Platform.

This entire process is a successive set of refinements that begins with a fast TLM model, adding more hardware detail as it becomes available while maintaining runtimes that are fast enough for software development. This ultimately enables the software and hardware teams – even across company borders – to have a common model that enables earlier communication and constant synchronization. This is the type of collaboration needed to keep pace with the innovation and delivery schedules required in today’s consumer market. It is only achievable if the hardware team evolves its design and verification methodology to encompass SystemC TLM.

Michael (Mac) McNamara is VP and general manager of system-level design at Cadence Design Systems. In the early 1990s, he helped start Chronologic, which brought compiled Verilog simulation to the world; thereafter, he cofounded SureFire Verification (which became part of Verisity) to improve the state of verification software. After Cadence acquired Verisity, Mac led the effort to improve high-level design, and currently manages Cadence’s C-to-Silicon Compiler and Virtual System Platform product lines.

Cadence Design Systems 408-348-7025 • mcnamara@cadence.com Linkedin: www.linkedin.com/company/cadence-design-systems Facebook: www.facebook.com/pages/Cadence-Design-Systems-Inc/66598923031 Twitter: @Cadence www.cadence.com

]]> http://tech.opensystemsmedia.com/fpga/2011/12/use-transaction-level-models-to-ensure-hardware-and-software-are-in-sync/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/12/virtual-or-real-prototyping-platforms-for-arm-based-fpga-design/ http://tech.opensystemsmedia.com/fpga/2011/12/virtual-or-real-prototyping-platforms-for-arm-based-fpga-design/#comments Tue, 06 Dec 2011 15:00:00 +0000 Mike Demler, Editorial Director http://tech.opensystemsmedia.com/fpga/?guid=ccee639b9f88a65a8881af118e6a2232

Modern FPGAs feature advanced DSP blocks and DSP resources that support a high degree of data processing and throughput. The challenge is to develop a high-level design flow that allows designers to
unleash the DSP capabilities of FPGAs. There have been several recent developments in DSP tools that have enabled the FPGA industry to excel in design productivity, reusability, fixed and floating point circuitry, and sheer computational throughput.

Many applications demand more DSP performance than DSP processors can deliver, such as radar, wireless, and broadcast video systems. To service these, an alternate technology has become prevalent: the FPGA. FPGAs grew out of their simpler CPLD cousins, and quickly grew in size and I/O capabilities. Once multipliers were introduced into the FPGA logic fabric, they became powerful DSP platforms. FPGAs soon contained hundreds and then thousands of multipliers. The multipliers morphed into DSP blocks that contained special circuitry to support FIR filters and FFTs. But the key advantage was the sheer degree of parallelism offered by FPGAs, which could not be replicated by DSP processors; high-end FPGAs contain billions of multiply accumulates per second compared to DSPs.

FPGAs are programmable hardware, and, with some exception, tend to have fairly static hardware configurations within any given design. The data processing tends to resemble a manufacturing assembly line, where each programmable circuit is configured to perform a specific function. This leverages the massive parallelism properties for the FPGA. This also leads to a different sort of design flow using hardware languages Verilog and VHDL. These languages describe the operation of the hardware at a fairly detailed level. They also accommodate the much higher degree of freedom offered by FPGA designs. In contrast to processors, the FPGA designer can use custom word widths tailored to the needs of the algorithm at each stage of processing. FPGAs offer thousands of memory blocks, allowing for easy storage of interim data states without the bottleneck of a single or few memory buses and interfaces used in processor architectures.

However, this degree of freedom tends to also make FPGAs more difficult to program, akin to DSPs in the assembly language era. Efforts have been made to develop C compilers for FPGAs, but they have had limited adoption to date. The developers of these “C-to-gates” tools face the challenge of describing parallel hardware architecture using a software language that is aimed at serial processing. When modifications are made to the software language to allow the designer to describe this parallelism, it tends to work against the inherent ease of use and familiarity of the programming language. Another challenge, similar to that experienced with DSP processor C compilers in the past, is being able to achieve the same level of FPGA efficiency and performance possible for designers using HDL languages Verilog or VHDL. Achieving the same level of performance with a high-level design flow is much more challenging than with DSP processors, again due to the many degrees of freedom offered by the FPGA architecture. Several recent developments in DSP tools can address these challenges of FPGA design, including model-based design and matrix processing.

Model-based design

An alternative FPGA design flow called model-based design utilizes MathWorks’ Simulink environment. The appeal of Simulink is that it understands the concept of clock cycles and allows for the description of hardware architectures, yet provides the fully integrated environment of MATLAB and Simulink to perform modeling and simulation of both the test bench and the system under development. Product offerings from Altera, MathWorks, and Xilinx allow development of FPGAs using an integrated tool flow where the designer operates largely within the MathWorks tool environment. The Altera and Xilinx Simulink-based tool flows naturally allow the designer to target only their respective FPGA products, while Simulink HDL coder allows the designer to target Altera or Xilinx FPGAs, or generic hardware for ASIC designers.

The various Simulink design flows tend to mimic the same techniques used in Verilog and VHDL. The designer specifies fixed-point word widths for each operation, determines the number of register delays or pipelining at each stage of the design, and utilizes local memory structures of various widths and depths. The tool output then passes to the FPGA vendor’s synthesis and place and route tools, after which the circuit Fmax and logic resource utilization can be determined.

Automating optimization

To introduce additional capability, another alternative allows the designer to describe what they want to do at an algorithmic level, and automate the many levels of optimization required to achieve high performance in an FPGA rather than trying to describe the design at the same level as HDL languages. For example, take a simple adder circuit. Normally, the designer needs to determine how much to break apart the adder chain and how many levels of pipeline registers need to be inserted. Within the Simulink environment, the designer describes an adder of any length (number of bits), the FPGA family used, and the Fmax at which the design is to run. The tool has access to all device timing details, so it can decide how much to break the adder chain and insert pipeline register stages in order to meet the designer’s Fmax requirements. This process is repeated throughout the entire design and frees the designer from the tedious process of optimizing the design to the latest device features or pipelining to meet the required clock rate (known as closing timing). This works well for small designs, such as individual FIR filters that can run at over 450 MHz, and large designs that can typically operate in excess of 350 MHz, which is on par with skilled HDL designer results. This results in a high degree of design portability and even “future proofing” of designs. The design itself is not optimized for a particular FPGA, but the tools can target a design for low-cost, mid-range, or high-end FPGAs (with allowances for reasonable Fmax). It will also allow a design to be optimized for future device families and features that do not exist today.

Multiple channels, folding, and polyphasing

Another development is the ability to perform multiple channels on any algorithmic datapath in a parameterizable way. The tool will automatically schedule the different channels to share resources and generate the necessary control logic. In fact, multi-channel often benefits the tool, as the multiple channels allow further pipeline registering to be done using the interleaved register delays necessary to accommodate the multiple channels, particularly for recursive designs. Folding, or use of the same resource for multiple operations within the same data stream, can also be performed as needed to reduce logic and multiplier resources. The contrasting technique, known as polyphasing, can be performed automatically, which allows the FPGA to interface to data convertors operating at multiple Giga Samples per second (GSps).

Floating point circuits and matrix processing

The ability to generate floating point circuits is one of the most significant advances now available to FPGA designers. Traditionally, FPGAs are not used for computing algorithms and linear algebra applications, as the tools and IP available were inefficient and too low performance. The dynamic range and numerical fidelity of floating point were simply not available to FPGA designers. This advance in FPGA tools changes this paradigm by offering high-performance floating point processing across a design in the largest FPGAs.

One of the biggest applications for floating point in FPGAs is matrix processing. Support for vector data types is available, allowing the designer to manipulate and perform operations upon entire vectors rather than describing each element in the vector. For example, a large floating point vector dot product, which is the fundamental building block of many matrix algorithms, can be described simply in a couple of multiply and add blocks.

DSP Builder from Altera Corporation allows designers to build their own matrix processing cores, which at runtime can support various sizes of matrices. BDTI, a DSP benchmarking company, recently evaluated this tool for high-performance floating point designs. The Cholesky decomposition, including forward and backward substitution processing, was chosen to demonstrate both design methodology and performance. This is commonly used for matrix inversion, particularly for a large class of problems utilizing covariance matrices.

Further benchmarks have been developed using 28 nm FPGAs, showing that six matrix inversion cores, each performing 3,000 matrix inversions (technically Cholesky decompositions) per second upon a [240 x 240] matrix can be implemented within a single large FPGA. This is an aggregate of 18,000 [240 x 240] matrices per second per FPGA. For smaller matrices, such as [20 x 20], a single FPGA can process up to 18,000,000 [20 x 20] matrices per second.

A designer might not need that level of performance, but, for instance, a radar application might need a throughput of 6,000 [240 x 240] matrix inversions per second, which would consume about one- third of a large FPGA’s resources. The remainder of the FPGA could be used for other functions, such as pulse compression, Doppler processing, and covariance matrix estimation. All of these can be implemented in the same FPGA, using a mixture of fixed or floating point processing as required. This alleviates many of the current data flow bottlenecks in complex systems such as modern radar.

On the path to a better DSP tool future

DSP chips now support both floating point and fixed-point circuits, so designers don’t have to choose between high-performance fixed-point DSP chip families or lower-performance floating point DSP families as they have in the past. DSP tools have also come a long way and will continue to evolve. Eventually, many expect that C or software-based descriptions of hardware architectures such as FPGAs will become competitive and ubiquitous. But today, recent design tool developments utilizing Simulink have hit the high water mark for design productivity, reusability, fixed and floating point circuitry, and sheer computational throughput.

Michael Parker is DSP Product Planning Architect at Altera. He joined the company in January 2007 and has more than 20 years of DSP wireless engineering design experience. He holds an MSEE from Santa Clara University, and a BSEE from Rensselaer Polytechnic Institute. He authored a book entitled “Digital Signal Processing 101,” published in 2010, and has published more than 20 technical articles on DSP, radar, and floating point.

Altera Corporation mparker@altera.com www.altera.com

]]> http://tech.opensystemsmedia.com/fpga/2011/12/new-developments-in-dsp-design/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/12/new-tool-for-fpga-designers-mitigates-soft-errors-within-synthesis/ http://tech.opensystemsmedia.com/fpga/2011/12/new-tool-for-fpga-designers-mitigates-soft-errors-within-synthesis/#comments Tue, 06 Dec 2011 15:00:00 +0000 Roger D. Do, Mentor Graphics http://tech.opensystemsmedia.com/fpga/?guid=66b44a7cf7904b73b4f38eb10b9991fb

New technology to protect against radiation-induced upsets and soft errors in FPGAs automatically adds
triple modular redundancy or safe Finite State Machine (FSM) encoding at synthesis. The approach
addresses an inexorable trend associated with Moore’s Law: As silicon geometries continue to shrink, the
possibility of soft errors or radiation effect upsets increase dramatically not only for aerospace applications, but also for FPGA designs destined for ground-level applications.

Radiation effects that can disrupt system operation and lead to circuit failure have long challenged engineers designing FPGAs for aerospace and high-reliability applications. Now, as silicon geometries continue to shrink, leading in turn to increased circuit density, these same radiation effects can potentially plague designs even at ground level. Yet even as the problem looms larger, a new technique to automatically add redundancy and other protection at synthesis stands to make things at least a little bit easier.

The alternative approach to adding redundant circuitry to a device is manually coding mitigation features in HDL, which does work despite being difficult, error prone, and not easy to verify. In addition, this approach often causes design performance to suffer quite a bit. For example, a simple counter can usually be coded in 13 lines of code. Manually triplicating all the logic takes more than 60 lines of code, including special coding structures that require specific, and most likely scarce, knowledge. Deep knowledge of the synthesis tool is also needed to prevent it from optimizing away the new logic a developer just sweated to add by hand.

By contrast, synthesis-based mitigation – which adds either multi-vendor, multi-mode Triple Modular Redundancy (TMR), or Single Event Upset (SEU)-detect safer Finite State Machines (FSMs) – requires less expertise in both HDL coding and the tool itself. The bottom line: Automatically inserting mitigation technology during RTL logic synthesis reduces the risk of functional errors and excessive impacts on performance and area utilization.

Multi-vendor, multi-mode Triple Modular Redundancy

Synthesis-based multi-vendor, multi-mode TMR comes in three forms. Deciding on which one to use depends mostly on the application’s mitigation requirements. In general, it’s safe to declare TMR to be a commonly used and proven methodology for radiation mitigation of Single Event Effects (SEEs) in FPGA devices. The methodology can be very effective but is not perfect, and, as is true for all protection options, its limitations must be weighed against other design considerations, such as where the FPGA will be used. For example, many designers of space systems are at pains to guard against hard errors, including single-event latch up, single-event gate rupture, single-event burnout, and total ionizing dose. Such errors are often best prevented with antifuse, flash, or SRAM hardened architectures

In contrast, FPGAs are used in a host of environments that, though less severe, still pose the risk of radiation-induced soft errors. These don’t permanently damage a device, but rather flip a digital “1” or “0” and thus snarl sequential or combinational logic. Synthesis-based mitigation that automatically adds either TMR or safer FSMs is most suited to soft errors.

TMR reduces single points of failure by triplication. Determining which units to triplicate will depend on the location of radiation-related weaknesses in the device. The three different TMR schemes described below protect different structures and guard against varying effects.

The first and most basic method is referred to as local TMR. Protecting sequential elements from SEUs involves tripling and then voting on registers and other sequential elements such as embedded RAM blocks, sequential DSP blocks, and shift-register blocks. The majority voter (Figure 1) votes out a single bit error, which is essentially masked by the other two correct signals.

Local TMR (Figure 2) only protects the sequential elements from SEUs, and, therefore, leaves the global clock network vulnerable. Additionally, the combinatorial logic, including the voters, remains susceptible to Single Event Transients (SETs). An SET occurs when an SEE causes a glitch to propagate through the circuit.

The second of the three TMR methods, distributed TMR, further protects against SETs in the combinatorial logic and voters (Figure 3). In addition to triplicating the sequential logic, distributed TMR also triplicates the combinatorial logic, including the voters. This eliminates the single points of failure in the combinatorial paths and voters, but leaves the global resources, such as clocks and resets, still vulnerable. Distributed TMR protects against both SEUs and SETs in the combinational logic, and also against configuration SRAM upset for user logic and data routes. SET protection may be a concern at high enough Linear Energy Transfer (LET)[1]. An added benefit of distributed TMR is that an SEU in the configuration memory of any of the data cones will be masked by the other two cones and voters.

A third TMR method, global TMR (Figure 4), includes all the mitigation of distributed TMR, where registers, combinational logic, and voters are triplicated, plus triplication of global buffers such as clocks and resets. This scheme outright eliminates the single points of failure in the user logic.

“SEU-detect” FSMs

Besides adding various forms of TMR, it’s now possible to automatically implement safer FSMs with synthesis. Safer FSMs may be preferred when protecting control logic is deemed to be the most critical mitigation goal. The basic principle behind a safe FSM is preventing the state machine from getting stuck in an unknown state due to an SEU. Consider a simple binary encoded FSM that uses only three states. Most synthesis tools run in default mode will optimize away all states that are unspecified or otherwise considered unreachable. Thus, when the device experiences an SEU and one of the register bits is inverted, the FSM can be put into an undefined, invalid state, which locks up the circuit.

The simple safe FSM available in most synthesis tools will implement all states, even those not explicitly specified, with defined behavior. However, one issue not accounted for is invalid transitions to otherwise legitimate FSM states, as shown in the simple binary FSM in Figure 5. Allowing these is unacceptable for many applications, hence the simple scheme really only works for one-hot encoding, an area-intensive alternative.

The new synthesis technology can implement “SEU-detect” safer FSMs, where full SEU detection can be done for all encoding schemes, such as area-efficient binary and Gray. The scheme uses a Hamming-2 algorithm that can detect any illegal state transition (Note that an SEU will still interrupt circuit operation, sending the safe FSM to a default/reset state).

A more automated, verifiable approach for NASA

Mentor Graphics Precision Hi-Rel, which launched in June 2010 as Precision Rad-Tolerant, incorporates mitigation circuitry during RTL logic synthesis. Precision’s Triple Module Redundancy technology was developed with guidance from NASA, which has decades of experience in dealing with radiation effects on everything from electronics to astronauts. As confirmed by their own research, most off-the-shelf devices, rad-tolerant or not, need additional protection if the radiation environment is severe enough. For example, devices that protect against SEUs may not protect against SETs at high enough LET levels. And in order to use large-capacity, low-cost, and reprogrammable commercial devices, extra protection typically needs to be provided for both SEU and SET mitigation. While hand-coding TMR is viable, the method is laborious and time consuming. NASA asked for a more automated, verifiable approach to TMR for SRAM-, flash-, and antifuse-based devices. As desired, the synthesis-based approach not only automates SEU and SET-level protection for these device architectures, but also provides an equivalence checking flow to make sure the new circuitry preserves original design functionality.

More a flu shot than a once-in-a-lifetime vaccination

Considering risks from radiation is a tricky business, involving lots of guesswork about everything from the cost of device failure to the likelihood that a scarce energetic particle will hit a device in just such a way as to cause a problem. Two things, though, are certain: First, radiation effects will remain a persistent concern, and not just for aerospace and defense applications, but also for other ground-level high-reliability applications. Denser tangles of circuitry in effect produce bigger targets for those stray particles. Second, while inserting protection at the push of a button is a novel approach, it’s not a foolproof and/or final inoculation. Addressing the issue of radiation will almost always involve weighing a combination of technologies that together meet design, budget, and mitigation requirements.

Roger D. Do is a senior technical marketing engineer at Mentor Graphics with more than 18 years of FPGA experience, including previous roles in applications engineering and product marketing with Texas Instruments, Lucent Technologies, Vantis Corporation, and Lattice Semiconductor. Roger holds a B.S. in Electrical Engineering from Texas A&M University.

Mentor Graphics roger_do@mentor.com www.mentor.com

References

1. J. Clerk Maxwell, A Treatise on Electricity and Magnetism, 3rd ed., vol. 2. Oxford: Clarendon, 1892, pp.68–73.

]]> http://tech.opensystemsmedia.com/fpga/2011/12/new-tool-for-fpga-designers-mitigates-soft-errors-within-synthesis/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/12/intelligent-chassis-management-for-mission-critical-vpx-systems/ http://tech.opensystemsmedia.com/fpga/2011/12/intelligent-chassis-management-for-mission-critical-vpx-systems/#comments Fri, 02 Dec 2011 15:00:00 +0000 Charles Linquist, Dawn VME Products Dawn VME Products Dawn VME Products http://tech.opensystemsmedia.com/fpga/?guid=25e529bbeb356e4b54e1834b4da9753a

As the military modernizes from basic control and text-based systems to nearly autonomous and vision-based platforms, the ever-increasing need for more complexity and processing power has forced military electronics to evolve as fast, or faster than, their commercial counterparts. But unlike the commercial world, where a nonoperational tablet computer is merely an inconvenience, a malfunctioning military system can cost lives. Thus, the old method of “swap it out when it fails” just will not do in the military. In the meantime, the VPX form factor is rapidly gaining traction in the military realm as a replacement for VME, and intelligent chassis management for mission-critical VPX systems as provided under VITA 46.11 is helping to ensure reliable performance when failure is not an option.

Military embedded systems are becoming more complex and expensive. The “black box” approach of replacing a system piece-by-piece until it works is no longer practical because of the costs associated with having two of everything.

Extreme reliability is therefore demanded from military systems, and while simulation and testing are extremely important, they can’t perfectly predict what an actual piece of equipment will be subjected to in the field, or how that equipment will perform on a long-term basis.

To ensure that equipment is not subjected to major environmental conditions that are outside the specification requirements, an intelligent chassis management system is required. In addition, a management system Error Log is indispensable for finding the conditions that led up to any failure, and can provide valuable feedback into the maintenance and design process so that future failures can be avoided.

The VITA Standards Organization (VITA/VSO) has provided the military with this monitoring, control, and logging system in the form of VITA 46.11 – System Management on VPX. This document defines a standard that allows chassis, backplane, board, and system designers to build compatible and interactive monitoring, control, and logging systems. In creating this standard, VITA adapted much from the PICMG 3.X standards.

The widespread adoption of VITA 46.11 will result in lower maintenance costs, quicker repairs, and the greater reliability demanded by military electronics. (Note: VITA 46.11 has not been fully ratified. To date, it is still a draft specification.)

PICMG 3.X is quite complex and very comprehensive, but because it was not designed for military applications, it has several shortcomings when used in a military setting. In commercial applications, the primary focus is to protect the equipment, but in military applications the focus is on protecting the mission. These differing needs affect the decision process that the monitoring and control system makes, but it doesn’t change the type and method of data acquisition.

In both PICMG 3.X and VITA 46.11, the Chassis Management Controller queries PROMs on each board for ID and other pertinent information. The consumer industrial Management Chassis Controller “asks questions and then turns on.” The military Management Chassis Controller “turns on and then asks questions.”

Protecting the mission chassis management

In a consumer-focused system, it might be frustrating if bootup takes several minutes, but it makes no huge difference if that is the case. However, in today’s wars, a battle may be nearly over in 2 minutes. Fast startup is a must.

VITA 46.11 recognized the need for fast startup and made that process much easier by stating that a system could check only a few major items before issuing the Start command. Detailed monitoring is started only after the system becomes operational. VITA/VSO also realized there are some situations where it is imperative that the system remains operational, regardless of any other condition. Such a condition would exist if a ship were under attack. Missiles must be fired even if the equipment is overheating. To provide for such a scenario, military systems usually employ a technique known as Battleshort. This is a mode that, once turned on, amounts to a “run until you melt” command.

VITA 46.11 integrates system management from the modules to the system. An Intelligent Platform Management Controller presents that module to the Chassis Manager. An I2C Intelligent Platform Management Bus, the IPMB link, then presents the modules to the Chassis Manager, which in turn presents the entire chassis to the System Manager. The System Manager can be linked to one or more Chassis Managers via high-speed bus such as Ethernet to form an OpenVPX (VITA 65) system. This high-speed link can be encrypted for security.

The System Manager monitors temperature, voltages, currents, fan speeds, airflow, acceleration, and any other desired parameter variations for which there are sensors. When critical thresholds are reached, programmed actions are taken. It’s important that parameters are logged for future reference of real-time system operability.

Because military contractors may be unfamiliar with the new system capabilities, Dawn VME Products has developed a set of diagnostic hardware tools that can run in conjunction with the System Manager in test or deployed systems. One example is the Intelligent Test Module, the ITM-6973, which is on a 3U board and performs stress tests and facilitates worst-case analyses (Figure 1). Under program control, it can load the system to any percentage of its capacity – including overload – thus proving that the system can handle normal and fault conditions properly while at the same time examining power supply response and temperatures by emulating system boards based on empirical profiles.

Such intelligent test modules are capable of providing dynamic loads to the system that can mimic virtually any board complement. The current loads are FETs, not resistors, which allow for the precise changing of currents on millisecond boundaries. It can also generate virtually any amount of heat – useful for testing cooling systems. Data log files are real-time stamped. The front panel has an I2C bus connector and a micro-USB connector that permits interfacing to a PC.

VITA 46.11: Power to the processor

Current military systems often require processor power not imagined only a few years ago. In drones, for example, several channel of video are gathered, but to send these images back at high frame rates and resolution would require enormous bandwidth. To make this task easier, the processor must compress the data before transmission. In addition, it may also have to encrypt the video stream to prevent access by enemy combatants. Also, onboard processing is required to distinguish the difference between moving and inanimate objects. These are just a couple of examples of increasing complexity and therefore challenges for mission-critical VPX systems.

Additionally, large memories, powerful processors, and other high-density semiconductors present inherent diodes with low reverse breakdown voltages and ultra-small trace insulation with low dielectric breakdown voltages. Voltage differences during power-up might exceed the reverse bias limits of these diodes or forward bias them to cause latch-up. These problems might be solved by writing code to control the order of voltage rails sequencing up or down once the System Manager has identified the particular problem board: VITA 46.11 wisely includes an error log as part of the specification.

Error logs, software upgrades, and system failure

The error log produced by the VITA 46.11 System Manager is extremely important. Design engineers and maintenance technicians must be fully aware of events leading to failure. Conditions in the field can never fully be anticipated by any test.

The VITA 46.11 System Manager is capable of recording virtually any condition. Figure 2 indicates connection paths to modules via the Chassis Manager. For example, during certain processing operations, the system might generate more heat than at other times. The System Manager can then be programmed remotely to increase fan speed during those intervals, thus ensuring that the system is always operating within specification, while at the same time power consumption is minimized by lowering fan speed when maximum cooling is not necessary.

The monitoring system can also provide clues on how the system software may be rewritten to lower temperatures and/or power consumption. Often a problem can be fixed by upgrading the System Manager’s software. This is certainly an elegant solution because this can be performed without moving the units. New code can be attached to an email and sent to the units’ location.

An upgrade in software can warn the System Manager that a particular board is a problem, and if certain conditions are detected, shut it down immediately. Maintenance would then replace the board with a spare. This would be a short-term fix until the particular board vendor fixes the problem.

Moreover, unusual combinations of circumstances such as vibration, temperature, humidity, power cycles, and other parameters over time might cause system failure. It is important that the cause of failure be identified as that of the customer or vendor. If the problem is that of the customer, such as exposing a unit to a harsh environment beyond specification limits, then the customer must modify their procedures or modify their requirements. If the problem is that of a particular vendor, then that vendor must fix the problem.

VITA 46.11: Standardized real-time system monitoring

With the adoption of VITA 46.11, industry has provided the military with a standardized real-time system monitoring capability that can easily be adapted to different situations by means of a large number of programmable parameters. The similarity of VITA 46.11 to PICMG3.X should reduce implementation costs and smooth the adoption process for intelligent chassis management in mission-critical VPX systems. This capability will result in lower maintenance costs, quicker repairs, and the greater reliability demanded from military electronics.

Charles Linquist is Chief Technical Officer at Dawn VME Products. He has 30 years of experience in mechanical, electrical, and software design with telecom, commercial, and military OEMs. He presently designs MIL-Spec-compliant enclosures, backplanes, and intelligent chassis management systems to enable military rugged, high-performance computing applications. He can be contacted at clinquist@dawnvme.com.

Dawn VME Products

510-657-4444

www.dawnvme.com

]]> http://tech.opensystemsmedia.com/fpga/2011/12/intelligent-chassis-management-for-mission-critical-vpx-systems/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/11/locking-the-embedded-deadbolt-separated-security-configuration/ http://tech.opensystemsmedia.com/fpga/2011/11/locking-the-embedded-deadbolt-separated-security-configuration/#comments Fri, 11 Nov 2011 15:00:00 +0000 J. Ryan Kenny, QuantumTrace http://tech.opensystemsmedia.com/fpga/?guid=ab47267280e83668c8bf16f8bf643c9f

The relatively recent expansion of high security features in embedded processors and architectures is beginning to affect embedded software tools in a variety of ways. Performing security configuration and code checking on a different platform from the user development environment separates security concerns from the rest of the development process and environment.

The process of developing, certifying, and implementing embedded security features has several problems that can be compared to providing deadbolts for residential properties. The deadbolt itself, no matter how well designed and tested, offers little security if it is not installed correctly. What’s more, the deadbolt is of no use if the owner does not lock it into place at night.

These problems likewise apply to chip security features. If implemented incorrectly by the system developer or not utilized at all, a processor’s security properties are of no value in the end system.

Where’s the security?

Embedded security features typically come to the marketplace as hardware or software solutions, though of course all security capabilities have aspects of both.

A good example of software security features includes a set of crypto libraries and reference codes used to protect data. The hard problems of creating encryption subroutines that are security certified, lack known coding vulnerabilities, and resist side-channel examinations are often undertaken by companies with security specialties and licensed to embedded developers. An example of hardware security features includes hard memory partitioning and hard trust modes and circuits invoked for sensitive operations. In both hardware and software cases, using the feature in a normal embedded development requires a configuration and software implementation step.

The implementation of security capabilities through vendor software tools is usually not a simple process. It is a product of the embedded development environment and must be performed in a way that is reliable, testable, and verifiable. Often it is integrated into the software development environment and provided to the developer bundled in the normal development suite.

Embedded development environment elements

The most common success metrics of an embedded development environment are productivity and ease of use. With high-security products and projects that fully utilize security features available on the market, however, an additional primary objective is to provide a trusted development environment.

This represents a high degree of either third-party certification of the software elements’ integrity or extensive documentation and interoperability testing of the embedded security configuration software and other development tools. Interface bugs that affect security configurations can have severe long-term consequences for development companies, not unlike liability in automotive and medical applications.

Implementing security configurations

Configuring security capabilities in an embedded system is done with a software development tool appended to the customer’s software development kit. Some examples include setting up bitstream encryption keys for an FPGA, fuse settings or hashing keys for a digital signature-checking circuit, and code obfuscation tools.

Though there are some exceptions, few vendors implement a digital signature or trust check on their own security configuration tools. This leaves the entire development environment vulnerable to code tampering, both intentional and unintentional.

A valuable approach to creating a secure design environment is performing security configuration and code checking on an entirely different hardware and network platform from the user development environment. In this way, the embedded user does not take on the burden of developing a security-pristine work environment, but instead isolates security concerns to a narrower range of the development schedule and tool flow.

Adding a secure configuration step

The goal of creating a secure configuration step is to segment security configuration as a separate step in the design process. If an embedded provider is developing an entirely new development environment, this becomes a value-add feature in early requirements. If this is being attempted with an existing or legacy design environment, the process might be more difficult.

An example of this process is the Acalis Sentry device, which is used to configure the security parameters of the Acalis secure processor. The processor’s security configuration resides in a uniquely encrypted and signed boot file, and the Acalis Sentry performs the step of creating a final encrypted boot file for the device.

A separate hardware appliance like Sentry can be used for a variety of other security configuration tasks as well. These include linking sensitive libraries, installing keys in final user configuration (in a similar fashion to military encryption equipment), or checking digital signatures and software licenses. Figure 1 shows how this security separation is implemented in an embedded development environment.

Another example of security separation is the process of separating data flows in FPGA designs. Both Xilinx and Altera offer the capability to partition data flow designs into separation regions. Each company also provides an independent verification tool to perform rule checking and layout management to ensure the design is partitioned correctly. In this manner, FPGA users who are designing for high-assurance systems can perform the most important step – verification – in a completely separated design environment if so desired.

Embedded security verification

Verifying security configuration settings differs greatly from embedded code testing. Testing refers to checking application code for operation to functional and performance requirements. Verification is the operation of this tested application code to ensure that the proper security safeguards are in place to prevent unauthorized access or tampering.

Performing write and read-back testing in security configurations is only as secure as the configuration tools and the communication channel used for testing. For this reason, three attributes of security verification testing are practiced widely in government security and are now lexicon steps in verifying embedded system code security. These attributes include authentication, command integrity, and audit logs.

User authentication

User authentication can be built into the security configuration tool (user name and password unique to the security verifier) or designed into the hardware host for security setting and verification software. The capability to match the verification module and the silicon device or software module being verified should also be provided.

Command integrity

Command integrity is a property of security command procedures that redundantly checks and rechecks or utilizes several command pathways to implement security configuration commands. This is similar to storage data integrity requirements that rely on forward error correction, redundant coded and fragmented data copies, and interdependence rules in logic that prohibit certain combinations of states.

Audit logs

Audit logs include a process of recording and securing the records of all transactions taking place from one logical module to another. It provides the benefit of a tracking mechanism for debugging and forensics, as well as vastly complicating the tampering process by creating and protecting an auditable trail of activity.

Secure features need secure processes

A great deal of publicity in 2011 has focused on how complex and integrated supply chains have become for large companies. The maze of suppliers contributing to an embedded system includes silicon designers, manufacturers, Real-Time Operating System (RTOS) providers, IP providers, design tools, debug/check tools, and so on. The complexity of this supplier picture presents issues for business risk and product security and integrity.

Providing guarantees regarding the security and integrity of each of these elements is an unsolvable problem as the issue of embedded security rises in the minds of customers and users. The smart way to address these customer concerns is to enable a secure process for verifying security features.

An important part of this approach is to isolate the process of implementing and verifying security configurations from the rest of the development process and environment. This will more than likely lead to the appointment of security specialists in an embedded organization and the rise of embedded security engineering as a best practice in product development. This could also result in development environments providing tools and capabilities targeted at supporting this emerging role. Given our society’s growing dependence on embedded technology, it’s safe to say this is a good thing.

With tools, training, and best practices, embedded systems designers will now be able to lock and secure the deadbolt in place on the front door. Then we can start to focus on all the unlocked windows elsewhere in the system.

J. Ryan Kenny is an electronic security consultant at QuantumTrace. He has more than 10 years of experience in space and defense electronics in the U.S. Air Force and defense systems engineering. He graduated from the U.S. Air Force Academy and completed an MSEE and MBA from California State University and Santa Clara University, respectively.

QuantumTrace jamesryankenny@msn.com www.quantumtrace.com

]]> http://tech.opensystemsmedia.com/fpga/2011/11/locking-the-embedded-deadbolt-separated-security-configuration/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/11/ee-daily-news-20-page-special-report-reviews-the-edaip-exec-panel-at-gtc2011/ http://tech.opensystemsmedia.com/fpga/2011/11/ee-daily-news-20-page-special-report-reviews-the-edaip-exec-panel-at-gtc2011/#comments Thu, 10 Nov 2011 15:00:00 +0000 Mike Demler, EE Daily News http://tech.opensystemsmedia.com/fpga/?guid=0c31cfc84149134e34b40c964b5913d8

The 2nd annual GLOBALFOUNDRIES Technology Conference (GTC), held in Santa Clara – CA on August 30, provided a rare opportunity to hear from leaders of each of the three largest EDA companies, along with the CEO of the largest semiconductor IP company, gathered together on the same stage to discuss a wide range of issues that will impact the future direction of the electronics design ecosystem.

Read more from Mike Demler’s EE Daily News

]]> http://tech.opensystemsmedia.com/fpga/2011/11/ee-daily-news-20-page-special-report-reviews-the-edaip-exec-panel-at-gtc2011/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/11/conexant-adds-keterex-audio-playback-ic-to-launch-new-product-line/ http://tech.opensystemsmedia.com/fpga/2011/11/conexant-adds-keterex-audio-playback-ic-to-launch-new-product-line/#comments Thu, 10 Nov 2011 15:00:00 +0000 Mike Demler, EE Daily News http://tech.opensystemsmedia.com/fpga/?guid=1a6fd31ff24e562739d5fb303b461902

Conexant has announced the launch of a new audio playback product line, starting with the addition of the KX1400, which the company has acquired from Keterex. Keterex designed the KX1400 to play 8KHz audio data directly to an external speaker via an on-chip digital audio processor and class-D amplifier that is capable of driving an external 8Ω speaker.

Read more from Mike Demler’s EE Daily News

]]> http://tech.opensystemsmedia.com/fpga/2011/11/conexant-adds-keterex-audio-playback-ic-to-launch-new-product-line/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/11/ti-claims-industrys-lowest-power-for-nfc-transceiver/ http://tech.opensystemsmedia.com/fpga/2011/11/ti-claims-industrys-lowest-power-for-nfc-transceiver/#comments Thu, 10 Nov 2011 15:00:00 +0000 Mike Demler, EE Daily News http://tech.opensystemsmedia.com/fpga/?guid=62b42e624e3dc8afdac53d98882e9f8b

New ways to enable designs for higher component power levels using conduction cold plates for the VPX standard are described. Particular interest is paid to materials with increased conductivity, through the introduction of secondary materials, such as graphite or heat pipes. Quantitative results of simulations comparing these materials are presented.

Within recent years, the demand of increased bandwidth for radar applications and faster signal speed up to 6.25 Gbps[1] through the connector have led to the introduction of VPX as a successor to VME, which was first introduced in 1981. Later, VME was upgraded to the VME64 standard to cater to 64-bit computing. Recently, with the introduction of the VITA 46 standard in 2006, which describes the VPX bus, a step was made toward higher power levels. This increased the power from a maximum of 90 W at 5 V within the VME standard toward a maximum of 768 W per card at 48 V within the VPX standard[1]. These increased power levels forced the emphasis toward more advanced cooling technologies, as simple solid conduction was commonly seen as insufficient to keep components within their operating temperature limits. Therefore, in 2010, four parts of the new VITA 48 REDI (“Ruggedized Enhanced Design Implementation”) have been officially released. The four parts consist of a generic mechanical specification (ANSI/VITA 48.0-2010); cooling using air cooling (ANSI/VITA 48.1-2010); cooling using conduction cooling (ANSI/VITA 48.2-2010); and cooling using Air Flow-Through cooling (ANSI/VITA 48.5-2010)[2].

The absence of a released version of the liquid-cooled part of the VITA 48 standard (VITA 48.3)[3], where the cards themselves rather than the chassis are liquid cooled, limits the possibilities to enable higher component power levels without exceeding the maximum allowable component temperatures of typically +125 °C or lower. In particular, this becomes more significant when utilizing the larger 6U size with a maximum length of 233 mm and a maximum conducting distance from the middle of the conduction cold plate to the cooled side rails of 116.5 mm. An example of a typical conduction path from a component on the board to the cooled side rails is shown in Figure 1.

[]

The following discussion examines some concepts for effectively cooling VPX designs via increased base material conduction through the addition of: aluminum cold plates, Annealed Pyrolytic Graphite (APG) cold plates, or two-phase devices such as heat pipes.

Comparison of conduction-cooling technologies

As part of the development of the cold plates, an investigation using commercial CFD software, Ansys ICEPAK V12.0, was used to quantify the reduction in component temperature by changing the conduction-cooling concept. To compare each of the concepts in an equal way, all conduction cold plates have a length of 6U (233 mm) and the same heat source layout, with a total heat load of 305 W. This limit was chosen to be close to the maximum heat load allowed for the 12 V VPX case, which is 384 W.

In addition to using the same heat source layouts and power settings, the mesh settings within the CFD software were kept constant, so the cooling concept and its unique materials were the only parameters changed between each of the CFD runs conducted. All cold plates have a main conduction thickness of 4 mm. The graphite insert presented here has a thickness of 3 mm, and the heat pipe version has twenty-four 3 mm diameter heat pipes embedded into the cold plate. Both types were modeled to ensure optimal isothermalization of the entire surface to be cooled. For all simulations, the side walls (see heat output areas in Figure 1) are maintained at +70 °C. The technologies are mentioned in the order of their thermal performance and not to be seen as a qualitative judgment or judgment with regard to their suitability for particular applications.

Aluminum cold plates

Solid aluminum cold plates form the benchmark for this investigation, and their particular advantage lies with their relatively low price in comparison to other technologies mentioned here. Additionally, they can be machined into many shapes and, if required, holes can be added in nearly any location desired. However, their thermal performance is limited and therefore their use is restricted to lower-performance applications, excluding many airborne and military applications.

Annealed Pyrolytic Graphite (APG) cold plates

APG cold plates, such as Thermacore’s k-core cold plates, are advanced solid conduction cold plates and can be used in many applications, where weight and increased thermal performance are of significant importance. APG cold plates are based on aluminum encapsulated Annealed Pyrolytic Graphite and combine the mechanical strength and CTE of aluminum with the increased thermal conductivity and reduced weight of graphite.

Due to its lightweight construction, gravity independence, and freeze/thaw resilience, airborne and space-based applications have become the main applications for advanced solid conduction cold plates. As a result, these cold plates are flight qualified for use on aircraft and spacecraft. To ensure a long product life, particular care has to be taken during the design phase, as the addition of extra mechanical features such as holes added to an existing design needs to be considered early in the design phase.

Two-phase enhanced cold plates

Two-phase enhanced cold plates draw their increased thermal performance from heat conduction through the base material of the cold plate enhanced by the addition of two-phase devices such as heat pipes. Heat pipes typically have effective thermal conductivities that are significantly higher than the base metal. Their superior thermal conductivity is based on the two-phase cycle, where a working fluid, such as water or methanol, for example, is evaporated inside the heat pipe at one section, condensed at another, and transports a heat load through its vapor phase.

Description of results

Results of the analysis of all three cooling approaches with respect to thermal resistance are shown in Figure 2.

In Figure 2, the thermal resistances indicated were taken at the central heat source modeled in each of the technologies investigated, with solid aluminum being the benchmark cold plate on the right-hand side. Because of the increased thermal conductivity of the APG, approximately 1,100 W/mK when encapsulated in 6061-grade aluminum[4], a reduction of thermal resistance of 63 percent is achieved when compared to the baseline aluminum cold plate, which has a thermal conductivity of 200 W/mK[5] for 6063-grade aluminum. Heat pipes with their thermal conductivity easily exceeding 25,000 W/mK, can reduce the value for the thermal resistance even further. When 3 mm heat pipes are embedded into the conduction cold plates, the overall thermal resistance is reduced by 90 percent in comparison to the baseline aluminum cold plate. This leads to very low component temperatures when compared to the other two cooling approaches. It should be noted that while APG cold plates (400 g) prove to be lighter than solid aluminum baseline cold plates (430 g), the superior thermal performance of heat pipe cold plates comes with a weight penalty because of introduction of higher-density copper material (510 g) for the 6U size.

Higher conduction means lower component temperatures

Conduction cold plates with enhanced material conductivity such as Thermacore’s k-core APG and heat pipe cold plates in the VPX format can be used to design electronic systems with power levels above that possible with pure aluminum cold plates, but can still rely on conduction cooling rather than utilizing active systems such as forced air, convection, or liquid inside the chassis. Additional applications of APG cold plates can be found in areas where weight is an important issue, such as airborne and space applications.

References:

1. GE Intelligent Platforms, “VPX: VMEbus for the 21st Century,” www.ge-ip.com, 2010.
2. Interconnection World, “VPX REDI standard reaches ANSI/VITA ratification,” www.interconnectionworld.com/index/display/article-display/8336317115/articles/connector-specifier/standards/2010/december/vpx-redi_standard.html.
3. VITA, “VME Technology Specifications,” www.vita.com/home/Specification/Specifications.html.
4. Montesano, M.J., “Annealed Pyrolytic Graphite,” Advanced Materials & Processes, June 2006
5. MatWeb, “Aluminum 6063-T6” www.matweb.com/search/DataSheet.aspx?MatGUID=333b3a557aeb49b2b17266558e5d0dc0&ckck=1.

Dr. Andreas Engelhardt is an Applications Research Engineer in the Applications Engineering Group at Thermacore Europe. Since joining Thermacore in 2005, he has served as the lead engineer or project manager on more than 15 programs. He holds an M.Eng (Hons) degree in Automotive Engineering from Newcastle, a Dipl. Ing. (FH) in European Mechanical Engineering from the University of Applied Sciences, and a PhD in Sustainable Energy Technology from the University of Nottingham. He is an inventor in one patent application. He can be contacted at a.engelhardt@thermacore.com.

Nelson J. Gernert is Vice President of Engineering and Technology at Thermacore, Inc. He has been with Thermacore since 1983, primarily working on R&D contracts related to heat transfer and heat pipe technology. His group of engineers and technicians develops technologies that enable future generations of electronic-based products in support of military, aerospace, and commercial applications. Nelson has extensive experience developing advanced thermal control technologies and moving them from the laboratory to production. He has published more than 50 technical papers and additionally holds 8 U.S. patents. He can be contacted at n.j.gernert@thermacore.com.

Jerome E. Toth, President, Chief Executive Officer, and Chairman of Thermacore, Inc., has more than 27 years of thermal management experience. He joined Thermacore in 1983 as a Technology Engineer and has subsequently held various positions in engineering, sales, and manufacturing. Jerome holds a B.S. in Mechanical Engineering from Rutgers University and 14 United States patents in the heat pipe and electronics cooling area.

Thermacore, Inc.

www.thermacore.com

]]> http://tech.opensystemsmedia.com/fpga/2011/10/novel-conduction-cooling-techniques-enablefull-vpx-functionality/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/10/altera-announces-soc-fpgas-with-dual-core-arm-cortex-a9-and-virtual-prototyping-support/ http://tech.opensystemsmedia.com/fpga/2011/10/altera-announces-soc-fpgas-with-dual-core-arm-cortex-a9-and-virtual-prototyping-support/#comments Tue, 11 Oct 2011 15:00:20 +0000 Mike Demler, Editorial Director http://tech.opensystemsmedia.com/fpga/?p=322 Altera has announced development of a family of ARM-based SoC FPGAs, which will provide users with single-chip solutions that integrate a dual-core ARM Cortex-A9 processor with Altera’s low power Cyclone V and Arria V FPGA fabrics. Todd Koelling, Sr. Product Marketing Manager for Embedded Processors at Altera, says that the SoC FPGA processor system will be based on a industrial grade dual-core 800MHz ARM Cortex-A9 MPCore processor, which the company will fabricate in a 28nm low-power process (28LP).

Each core in the Altera SoC FPGA processor system includes a ARM NEON media processing engine, and a single/double-precision floating point unit with 32KB/32KB  (instruction/data) of L1 cache per core.  The pair of processors share a error correcting code (ECC) protected 512-KB L2 cache. Additional hard IP in the SoC FPGAs will include up to three multi-port memory controllers with ECC for DDR2/3, Mobile DDR, and LPDDR2 memories. For Flash memories, the SoC FPGAs include a queued serial peripheral interface (QSPI) for NOR, and a NAND controller, both with ECC. Koelling says that the addition of ECC to the memory interfaces, which is usually omitted from PC applications, is critical to address signal integrity issues in high speed data transmission for industrial and military applications.

The SoC FPGAs also provide up to two PCIe Gen 2 x4 interfaces as hard IP, and soft IP is available for users who require x8 configurations of PCIe.

Altera has designed the SoC FPGA so that the processor system and FPGA fabric are powered independently, so that users can configure and boot the device in any order. Once in operation, users can power down the FPGA as needed to conserve system power.  The ARM Cortex-A9 MPCore processor system and FPGA fabric connect through ARM’s AXI interface, which Altera has configured as 256b bi-directional data paths at 200MHz (Cyclone) and 250MHz (Arria), for a peak bandwidth capability of greater than 125-Gbps with integrated data coherency. According to Altera, the processor system can deliver 4,000 DMIPS peak performance with less than 1.8 watts power consumption.

Altera has employed the ARM accelerator coherence port (ACP), so that users can implement accelerators in the SoC FPGA fabric that are cache coherent with the processor subsystem. Koelling says that use of the ACP increases system performance, which Altera has specified at up to 1,600 billion multiply-accumulate operations (GMACS) and 300 billion floating point operations (GFLOPS) from the variable precision DSP block.  The product family will include four lower end Cyclone devices, and two higher end Arria devices, offering a choice of performance and total power consumption from 2W (single core at 300MHz, commercial temperature range) to 15W (dual core at 800MHz, industrial temperature range).

Altera is also announcing a new development system for the SoC FPGAs, which the company  has dubbed a Virtual Target, based on Synopsys’ virtual prototyping solutions. Hardware designers will still be able to use Altera’s Quartus II design software, and the Qsys system integration tool. Software designers will be able to perform immediate device-specific embedded software development for the SoC FPGA devices, prior to availability of silicon. According to Altera, the Virtual Target is a binary- and register-compatible, functional equivalent of an SoC FPGA board, which will enable users to transfer software developed on the Virtual Target to the actual board with minimal effort.

Altera is supporting Linux and the Wind River VxWorks  real-time operating system (RTOS) in the Virtual Target, and software engineers can also continue to employ the ecosystem of ARM development tools. The Virtual Target includes the same processor and system peripherals that will be in the Cyclone V and Arria V SoC FPGAs, along with real board-level I/O connectivity to a host PC, including DDR SDRAM, Ethernet, USB and flash memory. Altera is also planning to offer an optional FPGA-in-the-loop extension to the Virtual Target, which will enable users to connect an Altera FPGA development board to the PC-based Virtual Target over a PCIe interface, for development of customer-designed FPGA-based IP.

Pricing and Availability

The SoC FPGA Virtual Target is available now for purchase from Altera.  Koelling says that Altera has worked with Synopsys to specifically adapt the Synopsys Innovator platform to the SoC FPGAs. The resulting solution will be sold by Altera as a complete turnkey solution, and it will include a seat of the Synopsys Innovator development environment. Altera is planning to have the FPGA-in-the-loop extension available early next year. Free downloads of a prebuilt GNU tool chain and Linux source also are available from Altera. A VxWorks board support package (BSP) will be available this quarter (Q4 2011) for the Virtual Target, and Altera plans to develop more BSPs for other embedded operating systems.

Altera is targeting  the second half of 2012 for availability of SoC FPGA silicon will be available, and reference designs and development boards will follow.  Pricing for Altera’s SoC FPGAs will start at less than $15 in high volumes.

High Power Amplifiers (HPAs) are critical in microwave systems commonly found in Electronic Countermeasures (ECM), Electronic Warfare (EW) simulators, radar, and communications links used by the military. Unfortunately, integral Vacuum Electron Device (VED) requirements introduce hostile environments for HPAs. However, a rugged, multifunctional, microcontroller FPGA-based controller can solve this challenge.

High Power Amplifiers (HPAs) are the backbone of most microwave systems used for military applications such as radar, Electronic Countermeasures (ECM), communication systems, and Electronic Warfare (EW) simulators. HPAs using Traveling Wave Tubes (TWTs) come in two categories. Both versions use Vacuum Electron Devices (VEDs), TWTs, Klystrons, and Gyrotrons to amplify the modulated RF waveforms given at the input to the desired power level before feeding to the radiating element.

The difference is that one version of the HPA is the microwave power amplifier with all RF input and output parts, power amplifying TWT (or other VEDs), digital interface and protection circuits, and the power supply all integrated into one assembly. The other version is the compact Microwave Power Module (MPM), which uses a miniature version of the TWT and a solid-state driver amplifier integrated with a densely packaged power supply (Sidebar 1). Being a very compact module, the MPM does not have all functions within the assembly and can produce RF power in the range of about 100 W CW or 1,000 W peak pulse power. The VEDs require high operating voltages of 5 to 25 kVdc and proper switching sequences and protection circuits.

Sidebar 1: An inside look: How microwave systems solve high-power electronic attacks (click graphic to zoom)

To keep the HPA controller functioning is vital for continued effective systems operation. Thus, to prevent damage to costly parts and the system, ongoing monitoring and status indication of every critical parameter are essential. For example, HPA controllers must monitor HPA health by measuring critical parameters such as the cathode voltage, current, body temperature, and so on. Controllers must also provide protection to prevent damage, in addition to offering interface between the HPA and host system, executing housekeeping functions, and functioning as the Built-In Test (BIT) system for the HPA.

In addition, HPA controllers must be able to withstand a “hostile” environment, as they reside in an area of the system where they can be subjected to high voltages up to 25 kVdc, high-energy switching up to 10 Joules, and other severe operational stresses such as extreme temperatures (-55 °C to +125 °C) and high vibration levels of up to 20 G rms. This is further complicated by the high levels of switching currents in the order of 100 A per microsecond and short-circuit currents of thousands of Amps. If such currents were to be going through any of the VEDs, it will destroy these expensive devices beyond repair.

The design challenge is to provide suitable protection and integrate BIT functionality and continuous monitoring into a microcontroller FPGA-based embedded controller because of the HPA’s “hostile” environment. Design engineers must consider the “hostile” environment factors prior to establishing the appropriate architecture for HPA embedded controllers. Figure 1 illustrates a basic HPA system architecture. Three major modules form an HPA system: a VED, a controller, and a high-voltage power supply that provides the required voltages to different elements of the VED such as the heater, cathode, collectors, and the electron beam. The HPA controller offers control and protection for the entire system.

Figure 1: The basic HPA system includes a VED, power supply, and HPA controller. (click graphic to zoom by 1.9x)

Protecting HPA systems’ critical components

Every HPA system requires control and protection circuitry to protect the VED and other critical system components from adverse conditions and possible failures that could lead to major system damage and considerable economic impact. There are several factors to consider when designing high-performance HPA embedded controllers. For example, the high operating voltages (5-25 kVdc) required by an HPA system can cause severe damage to sensitive components such as microprocessors, microcontrollers, FPGAs, memory devices, Analog-to-Digital Converters (ADCs), and other critical components. Extreme protection is required to keep these devices safe and active under any circumstance, especially when high voltage and switching current spikes occur. Current spikes of HPA systems can vary from a few Amps peak up to hundreds of Amps peak, depending on the VEDs’ requirements.

The hostile environment surrounding the embedded controller can also cause false alarm failures or unexpected behavior. Switching noise produced by the power supply switchers can produce extremely sharp noise spikes of nanoseconds duration, which can occupy more than a few MHz of bandwidth. These can corrupt critical signals of the HPA system such as Serial Peripheral Interface (SPI), Inter-Integrated Circuit (I2C), and serial data lines.

The HPAs need to meet various conditions such as time delay required by VEDs (180 seconds typical), operate command from the host interface, and Focus Electrode (FE)/grid enable and beam control (-1100 Vdc to +500 Vdc) prior to amplifying any given RF input signal of 2 to 40 GHz. The HPA controller must keep control over these signals and execute the commands in the right sequence under any condition to assure safety and proper functionality of the HPA system. Improper switching sequence of these signals could damage the VEDs, accidentally transmit RF output power (in some cases 10 kW peak), or harm personnel. Implementation of control signals with safe-state configuration is necessary to achieve a suitable and safe HPA controller. Safe-state signals will protect the VEDs from being active during initial power-up, standby, or when transmission is not desired. The integration of microcontrollers and FPGAs into HPA controllers empowers HPA systems by providing high-performance protection and extensive functionality, as will be discussed later.

“Universal” controllers satisfy next-gen systems

Modern mission-critical systems require HPAs that meet all performance requirements, provide 100 percent availability for the mission duration, and act as multifunctional HPA controllers capable of withstanding high-stress environments while effectively performing essential functions. A high-performance “universal” HPA embedded controller with an input power of +15 Vdc, 5 W, and dimensions of 6.0" x 2.5" x 0.90" can meet these requirements for next-generation military airborne systems. Figure 2 depicts its basic block diagram and hardware architecture.

Figure 2: Multifunctional embedded HPA controller powered by an FPGA and a microcontroller (click graphic to zoom by 1.9x)

The main function of this embedded HPA controller is to protect the critical elements of the system by monitoring the diverse parameters of VEDs such as Helix current up to 600 mA, cathode voltage from 5 kV to 25 kV, over-temperature (typical 125 ºC), and output reflective power up to 100 W average. These parameters vary from VED to VED, and the embedded controller offers flexible protection limits. It also monitors other critical parameters of the HPA such as input current, input voltage, and temperature of the high-voltage power supply. Additionally, the controller provides built-in test features through different serial communication protocols such as RS-422, RS-485, or RS-232. This function enables the host interface to continuously retrieve (automatically or upon request) the HPA system’s status. The HPA controller provides status between 1 and 2 seconds after application of power.

The embedded HPA controller can receive commands such as Model Identification Query, Status Query, Operate, and Stand-by, for example, from the host interface via the serial interface and execute these commands almost immediately (in less than 20 ms) after reception and acknowledgement.

Using a microcontroller, FPGA to protect the HPA

The microcontroller and FPGA components are the main core of the embedded HPA controller that protects the EW, ECM, radar, or other military system electronics from damage; these controllers perform the majority of the tasks with aid from the protection circuitry section and other miscellaneous devices, as follows:

• The main functions of the microcontroller are overall supervision, host communication, self-test, and technician assistance features via RS-232. The microcontroller also verifies board/system configuration, communication with a remote panel, and communication with other controllers, and conducts periodic verification of FPGA configuration to guard against single-event troubles.
• The protection circuitry continuously monitors the HPA system’s critical parameters by collecting feedback from various HPA elements. Such feedback could be temperature readings (-55 °C to 150 °C), cathode voltage, helix current, reflected output power from the VED, input under-voltage, and more. The input gate signal (pulse systems only) is detected by a pulse measurement function inside the FPGA to protect the VED from over-duty of 3 to 30 percent, over-pulse width of 2 µs to 300µs, and over-frequency of 200 Hz to 100 KHz. The protection circuitry also incorporates a high-speed pulse capture that accepts RF detector signals. These signals are conditioned, scaled, and digitalized, and the FPGA transmits the digitalized values through the serial interface.

The FPGA enhances the HPA controller by providing an extensive set of features to make it more robust and multifunctional. The FPGA architecture includes configurable functions via tailored logic loads, polarity, and mask registers to allow a common logic load for multiple HPA systems.

The FPGA provides control of a 12-bit ADC and compares configurable thresholds against digitized voltage inputs such as cathode voltage (scaled down from 5-25 kV to less than 10 Vdc) and detected RF output power (-80mV) from the VEDs (typically amplified and inverted from -80 mV to +10 Vdc). Additionally, the FPGA captures and analyzes digitized data, performs gate-pulse measurements (2-300 µs with frequencies up to 100 KHz), and provides voltage-to-power conversion using a lookup table, in addition to peak detection.

As a safety feature, the FPGA is configured to keep the I/O signals in safe-state; the microcontroller is capable of detecting any FPGA malfunction on the next polling cycle and taking appropriate action.

HPA controllers for today’s military systems

While HPAs are essential in most microwave systems used for military applications such as ECM, radar, communication, and Electronic Warfare simulators, it can be challenging to integrate the necessary protective functions into the HPA’s embedded controller. The hostile environment introduced by HPA systems because of the VED’s requirements is inevitable, and it compromises the integrity of HPA embedded controllers. Design engineers are obligated to live with this matter and must protect the embedded controller. dB Control has developed such an embedded HPA controller, which is microcontroller FPGA-based, noise immune, multifunctional, and firmware configurable, minimizing the need for design changes and harnessing FPGAs’ and microcontrollers’ high performance and extensive functionality to protect the system.

Mario Razo is a Design Engineer at dB Control, working with high-power amplifiers and microwave power modules for military and commercial customers. Email him at mrazo@dbcontrol.com.

Meppalli Shandas is dB Control’s VP of Technology and Business Development. He has 40 years of design experience with microwave hardware for Electronic Warfare, radar, and communication systems. Email him at mshandas@dbcontrol.com.

dB Control 510-656-2325 www.dBControl.com

]]> http://tech.opensystemsmedia.com/fpga/2011/09/designing-rugged-multifunctional-hpa-controllers-to-prevent-system-damage/feed/ 0 http://tech.opensystemsmedia.com/fpga/2011/08/new-virtex-7-fpgas-boost-software-radio-performance/ http://tech.opensystemsmedia.com/fpga/2011/08/new-virtex-7-fpgas-boost-software-radio-performance/#comments Wed, 03 Aug 2011 15:00:00 +0000 Rodger Hosking, Pentek, Inc. http://tech.opensystemsmedia.com/fpga/?guid=fe53ebc642657f46046484faa9d97be5

Wireless appliances in homes, offices, and vehicles … fixed neighborhood broadband wireless networks … the promise of seamless connectivity to the Internet in portable devices, regardless of location: These all drive the explosive demand for improved levels of service in this highly competitive Software-Defined Radio (SDR) market. This crowded radio spectrum means that to be competitive, carriers must squeeze as much traffic as possible into their licensed bands so they can deliver the required levels of voice and data service to the maximum number of subscribers.

In the government and military realm, organizations tasked with monitoring both domestic and overseas radio traffic for sensitive information must constantly upgrade system-loading capacities and develop new strategies to automate the information processing. Advanced radar systems must detect and identify stealthy targets at greater distances and track them with improved accuracy. Airborne countermeasure systems must constantly evolve in complexity to avoid detection.

The only viable solution to all of these problems is Software-Defined Radio. These systems replace traditional analog radio components with FPGAs and other digital signal processing hardware to deliver precise, complex modulation schemes to meet the constantly increasing demands of each application. Meanwhile, the new Xilinx Virtex-7 aims to address the most difficult application challenges in Software-Defined Radio engineering.

Virtex-7 FPGAs: Power, other considerations

The newest generation of FPGAs from Xilinx is the Series 7, consisting of three families each targeting specific price/performance spaces. The Virtex-7 family offers the highest performance of the Xilinx families with twice the performance of the Virtex-6. Figure 1 shows a comparison of Virtex-6 and Virtex-7, illustrating the performance and other improvements.

Figure 1: A comparison of Virtex-6 and Virtex-7

Virtex-7 devices feature low-power 28 nm process technology to implement up to 3.1 Tbits/sec of I/O and over 2 million logic cells. They provide up to 6.7 TMACs of DSP resources, especially important for Software-Defined Radio applications. Because of new process technologies and other power management schemes, they consume half the power of Virtex-6 for a given function.

Figure 2 shows the steady improvement in the past four generations of Xilinx FPGAs starting with the Virtex-4 and continuing to the Virtex-7. The graph displays the number of logic cells contained in a range of different density devices in a 35 mm x 35 mm BGA package. This clearly shows the dramatic increase in resource density, bounded by the constraints of the size and power dissipation.

Figure 2: The steady improvement in the last four generations of Xilinx FPGAs, starting with the Virtex-4 and continuing to the Virtex-7.

Challenge No. 1: DSP engine implementation

Software-Defined Radio signal processing algorithms for the new complex modulation waveforms require substantial computational horsepower, which isn’t always easy to come by. However, general-purpose processors execute software instructions sequentially on one or more arithmetic units, while FPGAs implement algorithms with numerous DSP hardware engines operating simultaneously in parallel. In this way, FPGAs not only improve algorithm processing speeds for a given channel, but given enough DSP engines, they can handle multiple channels operating in parallel. Because these engines are configured and connected by the designer, FPGAs can be tailored to meet a wide range of different applications to overcome most any design challenge.

Virtex-7 FPGAs use the DSP48E1 engines first introduced in the Virtex-6 family, each containing a pre-adder, a 25 x 18 multiplier, an adder, and an accumulator. The maximum quantity of DSP48E1 engines in Virtex-6 devices was 2016, while the Virtex-7 boosts the maximum count nearly two-and-a-half times to an impressive 5,280.

Challenge No. 2: Data converter interfaces

All Software-Defined Radio systems need A/D and D/A converters in the antenna path. To feed the insatiable demand for wireless data service, new wideband standards like UMTS and LTE can deliver wireless data rates up to 100 Mbps. But these services require advanced modulation schemes and channel bandwidths to 20 MHz and beyond. Advanced radar systems with sophisticated pulse structures call for signal bandwidths of 300 MHz and higher.

Because Software-Defined Radio deals so well with these complex waveforms, one major objective is to process signals as close to the antenna as possible. Fortunately, the latest Virtex-7 FPGAs provide a direct connection to high-speed peripheral devices with LVDS DDR I/O transfer rates reaching 1,600 MHz, up from 1,400 MHz in the Virtex-6. Applications such as a Virtex-7 XMC Software-Defined Radio module can use a 3.6 GHz A/D converter, taking full advantage of the high-speed I/O capabilities of the Virtex-7 FPGA.

To ease onerous printed circuit board layout constraints, Virtex-7 has per-bit skew adjustments to help align bits in a data word. They also include digitally controlled termination networks for tuning optimum performance while eliminating the need for external discrete resistors.

Challenge No. 3: Data buffering

While Software-Defined Radio A/D and D/A converters operate at a constant clock rate, networks and system buses transfer data most efficiently in packets or blocks. This requires staging of data in buffers that are sized to handle the worst-case delay until access is granted to use system memory. As data converter rates increase, buffer memory fills more quickly, shrinking the maximum buffer time and risking the loss of data.

Internal FPGA block RAM can be used as swinging or “ping-pong” memory buffers. Here one buffer fills from the source (like an A/D converter) while the other empties to the destination (like the PCIe interface), with roles reversing each cycle. Another very popular elastic buffer structure is the FIFO.

The largest Virtex-7 devices now offer more than 85 Mb of internal block RAM, more than twice as much as Virtex-6. Nevertheless, internal block RAM can fall short of meeting the required buffer sizes, and external memory must be used.

Challenge No. 4: Those external memory interfaces

Software-Defined Radio applications use large blocks of memory not only for buffering real-time data, but also to support complex signal processing algorithms. Thus, it’s a real problem when data buffers are too small or memory read/write cycles are simply not fast enough.

Synchronous DRAMs offer the densest and most economical solution for large memory arrays. Developed to support high-end PCs, DDR3 SDRAMs deliver extremely fast read/write rates by transferring data on both edges of the clock. The latest Virtex-7 devices can support DDR3 devices running a bit transfer rate up to 1.866 Gbps – far above the 1.066 Gbps for Virtex-6.

To achieve these speeds in the Virtex-7, the maximum 1:2 ratio between the fabric logic clock and the memory transfer rate on the Virtex-6 was boosted to 1:4 on the Virtex-7. Also new on the Virtex-7 is the Phaser clock generator that maintains real-time clock-to-data timing to within 7 psec. Designated interface pins allow a direct, glueless connection to these fast memories.

Challenge No. 5: High-speed interconnections

Since most Software-Defined Radio systems utilize real-time embedded system board-level products, high-speed interconnections such as Gigabit serial links and PCI Express are essential to handle the increased digital traffic between components, boards, and chassis to support new wideband signals. Needless to say, any bottlenecks for such wideband signal traffic will cripple real-time SDR operation.

In their latest Virtex-7 devices, Xilinx offers gigabit serial transceivers with four different maximum bit rates: 6.6 GHz (GTP), 12.5 GHz (GTX), 13.1 GHz (GTH), and 28 GHz (GTZ). This represents a dramatic increase over Virtex-6 maximum serial transceiver rates of 6.6 GHz (GTX) and 11.1 GHz (GTH).

These interfaces support popular protocols such as Ethernet, Aurora, SerialRapidIO, PCIe, and others. At the higher Virtex-7 rates for GTH, each 8x Aurora link can deliver bidirectional transfers up to 10 GBps.

Unlike Virtex-6 devices, some Virtex-7 devices now support the PCI Express Base Specification 3.0 with capabilities for both endpoint and root port. Since each PCIe generation also accommodates lower generation devices, the Gen3 interface operating at 8 Gbps is backward compatible with Gen1 at 2.5 Gbps and Gen2 at 5 Gbps. The x8 Gen3 PCIe interface provides a 6.4 GBps system interface.

Virtex-7 enhances SDR

When coupled with advanced power reduction techniques, more DSP engines for signal processing, improved buffering, and faster interfaces for data converter and memories, it is easy to see how developers can take advantage of the new Virtex-7 FPGAs to implement significant improvements in overall Software-Defined Radio system performance. CS

Rodger H. Hosking is Vice President and cofounder of Pentek, Inc., where he is responsible for new product definition, technology development, and strategic alliances. With more than 30 years in the electronics industry, he has authored hundreds of articles about digital signal processing. Prior to his current position, he served as engineering manager at Wavetek/Rockland, and he holds patents in frequency synthesis and spectrum analysis techniques.

Pentek

201-818-5900

www.pentek.com

]]> http://tech.opensystemsmedia.com/fpga/2011/08/new-virtex-7-fpgas-boost-software-radio-performance/feed/ 0 http://www.mil-embedded.com/articles/id/?5101 http://www.mil-embedded.com/articles/id/?5101#comments Mon, 11 Apr 2011 15:00:00 +0000 Jim Anderson, Xilinx http://tech.opensystemsmedia.com/fpga/?guid=0d244891e4c2373d927746074c0b16d0

Single-chip cryptography enables a cost-effective implementation of a UAV command and control system in a single FPGA. Partial reconfiguration capabilities in the programmable IC add SWaP-C savings because a less-dense, lower-power FPGA can host the design.

Over the past few years, the U.S. military and its allies have come to increasingly rely on Unmanned Aerial Vehicle (UAV) systems to carry out surveillance and combat missions around the world. Secure communication links are vital for UAV operation, both to control the UAV based on mission objectives and to reliably deliver actionable data to mission controllers on the ground. Encryption and decryption are inherent requirements, adding complexity and cost in the UAV electronics package. But with a single FPGA capable of meeting Type 1 cryptographic requirements, design teams can leverage reprogrammability and realize Size, Weight, Power, and Cost savings – referred to as SWaP-C savings. Xilinx and Advanced Communications Concepts, Inc. (ACCI) have demonstrated one such UAV communication and control system based on an FPGA.

The UAV application relies on a Single-Chip Crypto (SCC) design implemented in an FPGA to protect communications between the ground control stations and the UAV. The implementation completely safeguards the telemetry, video, and control data. The example system relies on the power of FPGA partial reconfiguration to provide algorithm swapping within a field-upgradable solution, all in a small product footprint.

Xilinx worked with the leading defense solution developers and key government agencies to develop an FPGA design flow and verification process that enables a single FPGA to meet Type 1 cryptographic requirements. The older method for meeting Type 1 cryptographic requirements employed two FPGAs – one to securely partition the unencrypted portions of the design. In the single-chip implementation, unused logic elements serve to implement the partitions.

The design flow isolates regions of the FPGA that handle red and black data and the encryption/decryption function (Figure 1). The red portions of the design deal with unencrypted data and must be isolated from the portions that deal with encrypted data. The SCC sits functionally between the red and black sides. The UAV example described here is based on a Virtex-5 FPGA using the SCC technology.

The UAV demo

At conferences such as MILCOM, Xilinx and ACCI have demonstrated an FPGA-equipped UAV providing a real-time encrypted flow of control, telemetry, and video data between the UAV and the ruggedized, laptop computer-based ground-control stations (Figure 2). The live-fly version has flown at events such as Air Force Joint Forcible Entry Exercise (JFEX) and the SOCOM/NPS Tactical Network Topology (TNT) exercises. They are being evaluated for use in various planes and systems, including UAVs.

The UAV command and control system uses a Virtex-5 FPGA with an integrated PowerPC processor. The system requires little more than the FPGA, MEMS accelerometers, and a physical layer for the wireless communications link. In developing the system, ACCI started with the SCC design flow and Xilinx’s information assurance techniques, and added a secure communications layer called Tactically Unbreakable Security Communications or TUCNet. TUCNet can encrypt any digital data stream. For example, it can handle video, telemetry, control, or even voice data packets.

ACCI doesn’t reveal TUCNet technical details for both security and competitive reasons. But more broadly, the company relied on features such as protocol hopping and encryption-scheme hopping to deliver a network layer that is secure over any type of wired or wireless network.

To meet Type 1 requirements ACCI had to isolate each of the regions of the FPGA according to defense agency specifications. Using Xilinx’s SCC methodology along with the Isolation Verification Tool (IVT), ACCI was able to implement this solution and provide necessary documentation validating the isolation.

Most notably, ACCI implemented the Type 1 requirements in a single FPGA. Prior to Xilinx’s work with government agencies and the validation of Type 1 cryptographic capabilities, a design would have used multiple ICs or subsystems to isolate the red and black data and the algorithms that operate on each. The SCC technology simplified the system implementation, resulting in SWaP-C savings. At a minimum, the SCC technology eliminated one FPGA from the implementation, halving the PC-board real estate needed to host the design. Power and cost aren’t halved, because the two-chip implementation might have used slightly less dense FPGAs, but the savings are significant and even the weight is reduced by a small amount.

Compounding the SWaP-C advantages

While meeting all security requirements for Type 1 cryptographic certification, ACCI’s FPGA algorithms and processing implementation compounded the SWaP-C advantages in the UAV application by using dynamic partial reconfiguration. The work Xilinx did on Type 1 cryptographic systems proved the ability to maintain proper isolation of red and black data even when reconfiguring a portion of the FPGA on the fly. With dynamic partial reconfiguration, the FPGA does not have to be big enough to hold all of the processing algorithms. It only needs to be big enough to simultaneously hold the single largest data-processing algorithm, the main control algorithm, and the SCC implementation.

ACCI utilized unique dynamic partial reconfiguration to add to the capabilities of the UAV control and communication system, and to minimize the SWaP-C burden of doing so. The system has a proprietary Hardware Operating System (HardwareOS) that is static in the FPGA. HardwareOS provides system resource allocation and system services functions that an OS would provide in a traditional software based system architecture.

The UAV system relies on a library of application or algorithm accelerators developed by ACCI. The TUC-enabled algorithmic accelerators enable, besides security functions, on-UAV, real-time manipulation of telemetry and video data streams and data transcoding functions. For example, if the UAV is in a banked turn, the video frame is horizontally distorted by both the pitch and roll angles of both the UAV frame and the camera pan and tilt settings. This problem was solved by dynamically loading and running an algorithm to “counter-rotate” video frames in real time into the proper orientation.

The TUC system also transcodes the digital video from RS-170 format to MPEG-2 and H.264 formats, among others. The system then combines the transcoded video with the telemetry from the autopilot, and other onboard sensors, into an MPEG transport stream that correctly emulates a Predator data download format. This allows the UAV data to be utilized by any system that currently handles Predator formatted data streams. And all of the data streams are encrypted for ground transmission.

The system can load every data packet transmitted to the UAV or every packet of captured telemetry or video data into static Block RAM (BRAM) on the FPGA, and then dynamically apply any desired sequence of algorithms to each packet as required. With TUC hardware acceleration, the entire frame processing of video stabilization, horizontal correction, Predator format transcoding, transport stream packaging, and encryption is done in less than 12 milliseconds. At 30 frames per second from the camera, 33 milliseconds are available between frames, thus allowing ample processing resources for future planned enhancements, such as automated target tracking and direct autopilot control.

A closer look: Dynamic partial reconfiguration

While using SCC flow to help maintain Type 1 requirements, the real advantage of using dynamic partial reconfiguration is apparent: The system can reconfigure the FPGA more than 100,000 times per second. Moreover, the data flow and parallel processing inherent in the FPGA fabric minimize latency and enable real-time manipulation to optimize gathered data for transmission to the ground station. The ACCI system encrypts the preprocessed data and transmits the secured data to the ground control station. The laptops used in the demo decrypt the data and present it to the user.

The partial reconfiguration capability enabled additional savings by allowing ACCI to utilize the smallest, ruggedized, defense-grade Virtex-5 family member that integrates a PowerPC. The XQ5VFX70T device chosen includes 11,200 Configurable Logic Blocks (CLBs) and a single PowerPC core. Without partial reconfiguration, the design requires a larger FPGA that would cost more and use more power. As an example, this can mean a 5x savings in just static quiescent power consumption between the smaller product and the next larger product in the Virtex-5Q family.

ACCI and Xilinx are working on a new version of the UAV demonstration system that will leverage the defense-grade Virtex-6 family and further compound the SWaP-C benefits. Virtex-6 FPGAs consume 50 percent less power than Virtex-5 FPGAs with a similar number of CFBs. Moreover, the Virtex-6 family is manufactured in a 45 nm process technology, versus a 65 nm process for the Virtex-5 family. Rather than requiring an FPGA with an integrated PowerPC hard core, the new version of the UAV system will yield further savings through the use of a soft core MicroBlaze processor.

Jim Anderson is a Senior Staff Defense Application and Architecture Engineer at Xilinx. Prior to joining Xilinx, Jim was an engineer at Philips Semiconductors and Sandia National Laboratories. He holds a BSEE from the University of New Mexico. Contact him at Jim.Anderson@xilinx.com. The author thanks Jonathan Ellis, CEO of Advanced Communications Concepts, Inc. of Austin, TX for his assistance with this article.

Xilinx 408-559-7778 www.xilinx.com

Editor’s note: Due to popular demand (and about twice as many articles and interviews as we could print in this edition alone), we share Part 1 of our special coverage on UAVs in this edition. Look for Part 2 in our June edition.

]]> http://tech.opensystemsmedia.com/fpga/2011/04/case-study-secure-fpga-technology-enables-uav-communications-and-control/feed/ 0 http://tech.opensystemsmedia.com/fpga/2008/12/tipping-points-in-programmable-logic-is-fpga-design-more-complex-than-asic-design/ http://tech.opensystemsmedia.com/fpga/2008/12/tipping-points-in-programmable-logic-is-fpga-design-more-complex-than-asic-design/#comments Tue, 02 Dec 2008 15:00:00 +0000 Andrew Dauman, Synopsysí Synplicity Business Group http://tech.opensystemsmedia.com/fpga/?guid=e95629483eda476ba82cfda9ced81e04

The ASIC world has many degrees of freedom; the FPGA world, not so much. But as Andrew Dauman, who will be presenting the keynote address at the first annual FPGA Summit, points out, far fewer than six degrees of separation may keep the two apart.

In the 25-year history of programmable logic, every year has
seen major business upheavals set off both by the application of Moore’s law to
the devices and by necessary design methodology adaptations. At the leading
edge of FPGA design, the techniques and expertise employed are every bit as
challenging and sophisticated as those used in ASIC design. In ASIC design, the
leading-edge CMOS geometries are used to create very large scale systems on a
chip. The parasitic and secondary effects of employing CMOS geometries at 90nm
and far below have led to front-end ASIC tools (and designers) having to be
more and more engaged in the back-end procedures. For example, most ASIC
designers demand the use of Physical Synthesis at the front end in order to
drive timing closure at the back end. Front-end ASIC designers are given
additional burdens of Design-for-Manufacturing, Design-for-Test,
Design-for-Reuse (IP), Design-for-Low Power, and the like, all of which are
complex and interdependent.

In the ASIC world, there are many degrees of freedom in the
end silicon, and the previously mentioned burdens of the modern ASIC designer
are all examples of the responsibility that comes with that freedom. The Electronic
Design Automation (EDA) industry has done a sterling job in providing tools that
allow these burdens to be borne and for ASICs to be produced at 40nm and soon
beyond – an astounding achievement that seemed impossible only a few
years ago.

FPGA designers, on the other hand, do not have such freedoms;
this is both their blessing and their curse.

FPGA vendors make enormous investments in creating a new FPGA
family. They are performing the very tasks mentioned above and they are doing
it not only for a single design, but to produce a device that addresses a very
wide range of applications. In effect, they are carrying the burden of 40nm
design for their end users.

How FPGA designers manage hurdles

Compared to ASIC designers, FPGA designers lack freedom. We
are limited to exactly the resources, timing, routing, power and other
parameters that are encapsulated into the FPGA silicon. This places extreme
constraints on FPGA tools and designer efficiency. An ASIC design team can place
fine-grain cells, create extra routes as required, or move resources while
considering the multi-axis trade-offs involved. In the FPGA realm, however,
cells are fixed and coarse-grained. What’s more, routing is finite with
quantized delays, so if we require an extra route where none is available, then
the effects often ripple widely throughout the design.

The predefined coarse-grained nature of FPGA architectures
would be an extremely difficult hurdle for today’s ASIC design teams if they
were faced with such fundamental constraints, so how do FPGA designers manage?

Traditionally, FPGA designers are not expecting a detailed level
of involvement in their designs; and this must not change. They work at an abstracted level from the silicon
and depend upon their tools to make the trade-offs mentioned earlier quickly,
automatically, and without error. At Synopsys, we have devoted more than 14
years of R&D effort to developing the methodology and tools that maintain
this abstraction, even at the very leading edge of FPGA technology. For
example, by modeling all routing resources, their timing, their sources, and
their blocking inter-dependencies, we created a Physical Synthesis solution
that combines Synthesis with Place and Route. Revisiting our earlier example,
routes may be ripped up and rerouted elsewhere to make room; on the other hand,
physical synthesis might more subtly employ local resynthesis in situ, thus altering the placement or even the actual logic
functions to be placed and alleviating the original routing bottleneck. In
effect, we combine the back end and front end in a single-pass automated
methodology.

As the R&D groups within the Synplicity Business Group
join those of Synopsys, we have new access to many and varied ASIC tool
technologies. Many of these are not applicable to FPGA, but some may prove to
be of crucial benefit to FPGA tool flows of the future. Beyond the delineated
worlds of FPGA or ASIC, an additional wider universe of system design waits,
including algorithmic modeling, embedded software, and virtual prototyping. We
have already teamed up to face those challenges, too.

Andrew Dauman, in
his role as vice president of engineering for Synopsys’ Synplicity Business
Group, oversees the development of programmable solutions for FPGA implementation,
ASIC verification, and ESL/DSP algorithm implementation.

Before joining Synopsys, Andrew was vice president of
engineering and vice president corporate applications engineering for
Synplicity, which Synopsys acquired in May 2008. He previously held positions
at Mentor Graphics, Silicon Compiler Systems, Prime Computer, and Raytheon.
Andrew has a BSEE from Boston University.

Synopsys
408-215-6000
andrew.dauman@synopsys.com
www.synopsys.com

The FPGA Summit takes place December 9-11 at the Wyndham
Hotel in San Jose, California.

]]> http://tech.opensystemsmedia.com/fpga/2008/12/tipping-points-in-programmable-logic-is-fpga-design-more-complex-than-asic-design/feed/ 0 http://tech.opensystemsmedia.com/fpga/2008/04/introducing-the-fpga-mezzanine-card-emerging-vita-57-fmc-standard-brings-modularity-to-fpga-designs/ http://tech.opensystemsmedia.com/fpga/2008/04/introducing-the-fpga-mezzanine-card-emerging-vita-57-fmc-standard-brings-modularity-to-fpga-designs/#comments Fri, 25 Apr 2008 15:00:00 +0000 Dave Barker, VMETRO, Inc. http://tech.opensystemsmedia.com/fpga/?guid=8fa8d2c9a5058bce672b8eb05b57430f

FPGAs are increasingly utilized in embedded system designs, especially in the I/O portion of embedded systems to implement complex I/O interfaces and perform in-stream data processing. A problem in the industry has been that the I/O interfaces are tightly coupled to FPGAs. This has limited the amount of reuse in FPGA designs because boards have to be designed specifically to handle a particular type of I/O. It has also limited the availability of COTS FPGA boards because it is difficult to design an FPGA with the right I/O for a wide range of customers. The new VITA 57 standard, also known as the FPGA Mezzanine Card (FMC) addresses these issues. The FMC standard defines an I/O mezzanine module that works intimately with an FPGA. An overview is presented of the FMC standard and the benefits it provides to developers.

With increasing frequency, FPGAs are showing up in the I/O portion or "front end" of embedded system designs to implement complex I/O interfaces, execute in-stream data processing, and even run user algorithms. FPGAs have naturally migrated to the front end of systems because they are so well suited to I/O and data stream processing; they have a large number of I/O pins, they have built-in support for a variety of I/O standards, and they have large amounts of logic that can be configured to implement protocols and process data. Because of the flexibility and reconfigurability of an FPGA, a single-FPGA design can be reused for a wide range of I/O by reconfiguring the FPGA and changing the I/O interface components such as the physical connectors or transceivers and any required I/O controller chips. However, this still requires a board redesign and respin. With the growing popularity of FPGAs in embedded designs, the embedded community could benefit from an industry standard method of modular I/O for FPGA designs.

For years, the PMC, and more recently the XMC, have provided an industry standard mechanism for a modular and flexible I/O design, primarily for use with 3U and 6U SBCs. The PMC/XMC form factors have been used extensively in the embedded computing realm, but they aren’t the optimal solution for modular FPGA designs. PMCs are much larger than an FPGA I/O mezzanine needs to be, they have the wrong type of and too many connectors, and the interface between the PMC/XMC and the baseboard (PCI, PCI-X, PCIe, Serial RapidIO, and so on) is much more complex and resource intensive than is required for an FPGA I/O mezzanine to interface to an FPGA.

Analogous to how PMCs provide modular I/O for SBCs, there is now an industry standard approach to providing modular I/O for FPGA designs – the FPGA Mezzanine Card (FMC). The FMC (also known as VITA 57) standard was developed to provide an industry standard mezzanine form factor in support of a flexible, modular I/O interface to an FPGA located on a baseboard or carrier card. It allows the physical I/O interface to be decoupled from the FPGA design while maintaining a close coupling between a physical I/O interface and an FPGA. This approach separates FPGA board designs into two pieces – a carrier and a mezzanine. The carrier contains one or more FPGAs and the associated functionality that will always be common to any variation of the board design. The mezzanine contains the functionality that can be variable within a board design, such as the I/O portion of the design.

The FMC approach solves the problem of how to change the I/O configuration of an FPGA design without having to redesign the core FPGA functionality. The FMC brings to FPGA designs the benefits of PMC modules that embedded developers have come to rely on. These benefits include shorter design cycles, increased ease in taking advantage of technology advances, and lower development and recurring costs. An overview of the standard follows.

FMC standard overview

The FMC standard defines an I/O mezzanine module that works intimately with an FPGA. The standard defines two widths – single and double width. Figure 1 illustrates that the single-width module, which measures 69 x 76.5 mm, is approximately half the size of a PMC module, and supports a single connector, P1, to the carrier. The double-width module measures 139 x 76.5 mm and can support one or two connectors to the carrier, P1 and P2. The double-width FMC is for applications that require additional bandwidth to the carrier, more front panel space, or a larger PCB area. As is the case with most commercial PMC/XMC modules, most commercial FMCs will be single width.

There is a choice of two different connectors to interface the FMC to an FPGA on a carrier: a Low Pin Count (LPC) connector with 160 pins and a High Pin Count (HPC) connector with 400 pins. An FMC with the LPC connector can mate with a carrier that utilizes either an LPC or HPC connector. To support the widest range of FMCs, commercial carriers should utilize the HPC connector. The FMC specification was developed to enable FMCs to be supported on a wide range of existing form factors including but not limited to VME, CompactPCI, VXS, VPX, VPX-REDI, CompactPCI Express, AdvancedTCA, and AMC. Figure 2 shows three FMCs fitted to a 6U VPX carrier.

The VITA 57 connector was chosen to ensure developers have the functionality and performance they need to allow them to move their I/O to a mezzanine card. The connector is designed to support single-ended and differential signaling up to 2 Gbps and signaling to an FPGA’s Multi-Gigabit Transceivers (MGTs) up to 10 Gbps. The LPC connector provides 68 single-ended user-defined signals or 34 user-defined differential pairs, one MGT pair, clocks, a JTAG interface, and an I2C interface to optionally support the base IPMI commands. The HPC provides 160 single-ended user-defined signals or 80 user-defined differential pairs, 10 MGT pairs, and additional clocks.

To meet the demands of high-performance embedded computing, the FMC connector can support very high bandwidths; a single differential pair can provide 2 Gbps of bandwidth when clocked at 1 GHz since data can be transferred between the FMC and the carrier on the rising and falling edges of the clock. Even when clocked at a conservative 250 MHz, 32 differential pairs provide 2 GBps of bandwidth (250 MHz x 2 clock edges x 32 bits/8 bits/bytes). As an example, a quad 215 MSps 12-bit ADC FMC would transfer data at a rate of 1.29 GBps (215 x 12 bits/ADC x 4 ADCs/8 bits/byte). Utilizing 48 differential pairs (12 bits/ADC x 4) of the HPC connector clocked at 107.5 MHz (one half of the ADC sampling rate) would provide the required bandwidth to move the data from the four ADCs into the FPGA on the carrier.

The MGT interfaces are most useful for supporting protocols that run over multi-gigabit serial links. Moving the copper connectors or fiber optic transceivers from the base-FPGA design to an FMC mezzanine card makes it much easier for a single FPGA design to support various physical interfaces. Next-generation ADC and DAC chips that support the JEDEC JESD204 standard (Serial Interface for Data Converters) interface will directly connect to one or more FPGA MGT ports. Converter chips supporting JESD204 interfaces, such as the Linear Technology LTC 2274 16-bit 105 MSps ADC, are expected to hit the market in 2008.

The FMC standard defines both air- and conduction-cooled form factors. The conduction-cooled form factor can receive all I/O over the P1 connector, or it can support front-panel I/O if necessary. Also defined in the standard is a front-panel bezel, clearly visible in Figure 3, which is very similar to PMC front-panel bezels.

The FMC standard provides for a great deal of flexibility in the interface between the FMC and carrier to support a wide range of functionality FMCs may provide. Flexibility in standards typically equates to incompatibility and fragmentation of the market, but this is not the case with the FMC standard. Even though there can be a wide variability in the number of I/O pins from FMC to FMC, due to the reconfigurability of FPGAs, as long as an FPGA has sufficient I/O pins mapped to the FMC site connector to support a particular FMC, the FPGA can be configured to support that FMC.

FMC benefits

Not surprisingly, an FPGA-based design utilizing an FMC has the same benefits as industry standard mezzanine cards that have been around for years, such as PMC modules, or the newer form factors such as XMCs. The same benefits of utilizing mezzanine cards in CPU-based computing are now available for FPGA-based designs.

One major benefit of VITA 57 is shorter development cycles for design variations. It is intuitive to see that it will be much simpler to change to a new I/O interface if the design utilizes an FMC approach. If an FPGA design needs to support a second I/O interface, the savings will not be profound; the real savings come when a single FPGA design can be utilized in multiple applications or programs by simply developing a new FMC.

Another benefit that mezzanines have provided for years is an improved ability to take advantage of technological advances. If there are advances in I/O, a new FMC module can interface to an existing FPGA carrier. Likewise, when next-generation FPGAs become available, existing FMC modules can be interfaced to the new FPGA carrier to take advantage of the latest in FPGA technology.

One other important benefit is cost. Being able to reuse either FMCs or FPGA carriers, whether using in-house developed boards or COTS designs, will reduce both development costs and recurring costs through the use of fewer and common components across multiple programs. As is the case with PMC modules, the real cost savings will come when developers can purchase off-the-shelf FMCs or FPGA carriers and not have to develop their own boards.

Looking back provides a glimpse into the future

The benefits of PMC modules didn’t come about overnight. It wasn’t until there was critical mass of commercial SBCs with PMC sites and commercial PMC modules that the embedded community was able to realize the inherent benefits. By now, the PMC approach has been taken for granted by developers, and these benefits are expected. The same will happen with FMCs – it will be expected that future FPGA designs will be based on the FMC approach.

Whether designing a proprietary (in-house design) embedded system, purchasing COTS products to integrate, or using a combination of in-house and COTS products, if the design includes FPGAs, the FMC standard can and will make the system designer’s job easier. The standard has gone to the ANSI balloting process but as with many other draft standards, vendors are already developing products around it. There have been no announcements yet, but we should start seeing commercial FMC mezzanines and carriers hit the market in the first half of 2008. CS

Dave Barker is the vice president of market development for embedded solutions at VMETRO. Before joining VMETRO in 2005, Dave was the marketing manager for VME products at the Motorola Computer Group and has worked in the industry for more than 25 years. Dave has a BS in Computer Science from the University of Pittsburgh and an MBA from the University of Phoenix. He can be reached at dbarker@vmetro.com.

VMETRO, Inc.
281-584-0728
http://www.vmetro.com

]]> http://tech.opensystemsmedia.com/fpga/2008/04/introducing-the-fpga-mezzanine-card-emerging-vita-57-fmc-standard-brings-modularity-to-fpga-designs/feed/ 0 http://tech.opensystemsmedia.com/fpga/2008/01/accelerating-algorithms-in-fpgas-one-process-at-a-time/ http://tech.opensystemsmedia.com/fpga/2008/01/accelerating-algorithms-in-fpgas-one-process-at-a-time/#comments Tue, 01 Jan 2008 15:00:00 +0000 David Pellerin, Impulse Accelerated Technologies http://tech.opensystemsmedia.com/fpga/?guid=d3ec56474e3105cfc90df5cdac8853d4

FPGAs have become commonplace in embedded systems and are now beginning to appear in high-performance, server-class computing applications as well. This shift toward hardware-accelerated computing has been driven by two factors: increased FPGA device capabilities and improved software-to-hardware tool flows. Emerging tools can help demystify FPGAs, making them more accessible to software application programmers.