www.vmecritical.com
Features Software: Safety-critical software takes flight 14 August 2008 Volume 26 Number 3
Eclipse helps overcome development challenges in modern safety-critical IMA systems By Larry M. Kinnan, Wind River
17
Columns
Next-gen C++ API for avionics apps enhances application development By Troy Troshynski and Gabe Cook, AIM-USA
VITA news
The invasion of the form factors
8
By Ray Alderman
VME in Europe RapidIO in Europe
9
By Hermann Strass
VITA standards update
VITA 57 completes ANSI ballot while VITA 49 preps for ANSI
Technology: The size of VITA’s standards 20
When half isn’t exactly half: 3U vs. 6U VPX
22
Making COMs rugged enough for harsh applications:
10
VITA 59 opens the door for true standardization By Stephen Cunha, MEN Micro Inc.
By John Rynearson
VITA standards activity chart
12
Editor’s foreword
30
New processors: Choose wisely By Chris A. Ciufo
24
Automated CDC verification protects complex electronic hardware from metastability failures
E-letter
Editor’s Choice
27
New Products
28
By Cliff Witte
Hardware: CDC guards FPGAs, ASICs
By Michelle Lange, Mentor Graphics Corporation
Departments By Chris A. Ciufo
By Thomas Nygaard, VMETRO
www.vmecritical.com/eletter VITA 49 enhances capabilities and interoperability for transporting SDR data By Robert Normoyle, DRS-Signal Solutions
Successful system integration considers COTS, GFE, and custom Q&A with David M. Dietz, Vice President and General Manager, CWCEC Santa Clarita
On THe cOver: AMD’s new quad-core Phenom processor supersedes the company’s mainstay Athlon desktop family. Available in three- and four-core versions, the Phenom complements AMD’s Opteron server processor family. In our Special Software Issue this month, we present for you several articles and numerous products with a software twist: from static analysis code verification, to a way to partition die clock domains in order to comply with DO-254 (the hardware equivalent of the FAA’s safety-critical software specification DO-178).
All registered brands and trademarks within VME and Critical Systems magazine are the property of their respective owners. © 2008 OpenSystems Publishing © 2008 VME and Critical Systems
Published by:
4
OpenSystems Publishing™
VME and Critical Systems / August 2008
Power.org’s new architecture roadmap: Upscale with more cores Q&A with Fawzi Behmann, Marketing Committee Chair, Power.org
VXS versus VPX: Either – or both? By David Compston, GE Fanuc Intelligent Platforms
Web resources Subscribe to the magazine or E-letter at: www.opensystems-publishing.com/subscriptions
Industry news:
Read: www.vmecritical.com/news Submit: www.opensystems-publishing.com/news/submit
Submit new products at: www.opensystems-publishing.com/np
A
O
n
p e n
S
y S t e m S
p
u b l i c A t i O n
Military and Aerospace Group
n n n n n n n n
DSP-FPGA.com/E-letter DSP-FPGA.com Resource Guide Military Embedded Systems/E-letter Military Embedded Systems Resource Guide PC/104 & Small Form Factors/E-letter PC/104 & Small Form Factors Resource Guide VME and Critical Systems/E-letter VME and Critical Systems Resource Guide
Group editorial Director Chris A. Ciufo cciufo@opensystems-publishing.com Associate editor Sharon Schnakenburg sschnakenburg@opensystems-publishing.com Senior editor (columns) Terri Thorson tthorson@opensystems-publishing.com Assistant editor Robin DiPerna new Products editor Cliff Witte european representative Hermann Strass hstrass@opensystems-publishing.com Senior Web Developer Konrad Witte Web content Specialist Matt Avella creative Director Steph Sweet Art Director David Diomede circulation/Office Manager Phyllis Thompson subscriptions@opensystems-publishing.com OpenSystems OpenSystems Publishing Publ hing™
Editorial/Production office: 16872 E. Ave of the Fountains, Ste 203, Fountain Hills, AZ 85268 Tel: 480-967-5581 n Fax: 480-837-6466 Website: www.opensystems-publishing.com Publishers vice President editorial
John Black, Michael Hopper, Wayne Kristoff Rosemary Kristoff
Communications Group editorial Director Managing editor Senior editor (columns) Technology editor european representative
Joe Pavlat Anne Fisher Terri Thorson Curt Schwaderer Hermann Strass
Embedded and Test & Analysis Group editorial Director editorial Director Senior Associate editor Special Projects editor european representative
Jerry Gipper Don Dingee Jennifer Hesse Bob Stasonis Hermann Strass
VME and Critical Systems (USPS 003-443) is published five times a year (Feb, April, Aug, Oct, Dec) by OpenSystems Publishing LLC, 30233 Jefferson Avenue, St. Clair Shores, MI 48082. Print ISSN 1941-3807, Online ISSN 1550-0403. VME and Critical Systems is free to qualified engineers or management dealing with or considering open system technologies. For others, paid subscription rates inside the US and Canada are $45/year. For first class delivery outside the US and Canada, subscriptions are $60/year (advance payment in US funds required). Periodicals postage paid at St. Clair Shores, MI, and at additional mailing offices. canada: Publication agreement #40048627. Return undeliverable Canadian addresses to: WDS, Station A, PO Box 54, Windsor, ON N9A 615. POSTMASTer: Send address changes to VME and Critical Systems 16872 E. Ave of the Fountains, Ste 203, Fountain Hills, AZ 85268
6
VME and Critical Systems / August 2008
By Ray Alderman
T invasion of the form factors The It should come as no surprise to you that we are awash in new form factors in the embedded space. Form factors are essentially the size (length, width, and depth) and orientation (front, back, and sides) of a PCB. This proliferation of form factors has some benefits, as well as many bad effects on the embedded board markets. Why we have so many new ones certainly suggests surreptitious, clandestine, nefarious, heinous, and unscrupulous reasons for their existence. The objective of this column is to expose this conspiracy, and make you aware of the dangerous and depraved world we live in.
just for starters. If that wasn’t confusing enough, there are totally random variations of these form factors, designated by such adjectives as Baby, Nano, Pico, and Micro preceding the acronym. And, these preceding adjectives lack, in any conceivable way, any direct bearing on the PCB’s size. Surely there is a “femto” in our future as this craziness continues. Maybe even a “Groucho,” a “Chico,” and a “Harpo.” These are mostly motherboard form factors that came down from the commodity desktop computer marketplace with the same subtlety as the Huns invading Europe. But wait. There’s more bad news.
First, we need a scientific taxonomy of form factors to classify There is a whole load of smaller board sizes in this category them for better understanding and to make the clandestine origins with names like PC/104-Plus and COM Express. They all difof many of them pop out. Taking this chore into my own hands, fer by only a few millimeters in dimensions, the connectors they since no one else has done it with any clarity, I see basically three use, and the company that makes them. If we want to get into categories of board form factors: 1. Rack mounted (the PCBs deeper taxonomy here, this would be called the small form factor are easily inserted or removed from a rack, without tools, in a phylum. This particular group of board sizes exposes the most matter of seconds, and without divine intervention); 2. Canned glaring, repulsive, and grotesque mutations in the entire history (the PCBs are enclosed in some kind of of PCB fabrication. container and not easily inserted or removed Three categories: without the use of tools, a lot of time, and Finally, we have the snap-on category. divine intervention); and 3. Snap-ons (mezThese are mezzanine cards that snap onto 1. Rack mounted; zanine cards that snap onto one of the form one of the other form factors in the 19-inch 2. “Canned”; and factors in 1 or 2 above). Of course, PMC/ rack segment, or onto the larger canned form XMC/AMC mezzanine cards fall into this factors. They enable easy and low-cost cus3. Snap-on. category. I am sure that I could concoct a tomization of the parent PCB (the form facspecies-genus-family-order-class-phylumtor they snap onto) to meet the application kingdom-domain-life taxonomy here, but I am only allotted a or customer requirements. Their dimensions are consequently finite amount of space by my evil editorial masters. So, this will dictated by the size of the parent PCB, but that limitation has not have to do for now. delayed designers from their appointed proliferation objectives. They carry names such as PMC, XMC, FMC, and AMC, to list a In the rack-mounted arena, we are bound by the 19-inch rack few. However, I see mezzanine form factor derivations as a neces(or in telecom, the strange, disproportional, and comical 21-inch sary evil. They are one of the few form factors derived from comrack). Here, all PCBs are defined in height (a unit of measure mon sense and need, and are acquitted of conspiracy charges. called a U, which is 1.75 inches), depth (typically in 60 mm increments), and width (the horizontal distance between boards So, why do we have so many form factors? Because certain comin a rack, referred to as the pitch, measured in inches or millipanies want to make the markets for boards heterogeneous by meters, depending upon which side of the Atlantic you reside). fragmenting them into ever-smaller niche segments. Then the big So, there is some order in the chaos of proliferating form factors, companies can’t play in such small segments, or play in all of but only in the 19-inch rack kingdom. However, we still have them, so certain companies have a nice protected business envi3U, 6U, 8U, 9U, and 12U cards available, with depths of 160 mm, ronment. That is the conspiracy underlying the proliferation of 220 mm, 280 mm, 340 mm, and 400 mm. We also have pitches form factors. This proliferation has nothing to do with application of .6, .8, and 1.0 inches, from my empirical observation. While needs or customer requirements in most cases. It has everything somewhat prolific, at least there are internationally accepted to do with companies trying to create protected markets. standards for these form factor derivations. This fact exonerates the rack-mounted form factors from the conspiracy theory menWith the concurrence of my evil editorial masters, we have created tioned previously. VME and VXS boards are all 6U x 160 mm a list of more than 100 different form factors, including the owner (with pitches of either 0.6 or 0.8 inches for conduction- or airof the specification, the dimensions of the PCBs (even the mutant board sizes), and other revealing information. This list is availcooled boards, respectively). VPX boards can be 3U or 6U tall, able at www.smallformfactors.com/list. Make sure you check out but both are 160 mm deep. And, the pitch of these boards can this exclusive, exhaustive, and ever-expanding list. It will be a be 0.6, 0.8, or 1.0 inches, depending on how they are cooled memorable experience for you, just as writing this column was (conduction, air, or liquid). for me. Now, we must enter the mushy morass of canned form factors. For more information, contact Ray at exec@vita.com. They have names such as EBX, ITX, ATX, ETX, AT, and NLX,
8
VME and Critical Systems / August 2008
By Hermann Strass
RapidIO in Europe The RapidIO interconnect architecture was designed to be a high-performance, packet-switched, crossbar, or switched pipeline interconnect technology. It addresses the high-performance embedded industry’s need for reliability, increased bandwidth, and faster bus speeds in an intrasystem interconnect. The RapidIO interconnect allows chip-to-chip and board-to-board communications at performance levels scaling to 10 Gbps and beyond. A key feature is low latency and low overhead. RapidIO has been under active development since 1997. It has its roots in RACEway (ANSI/VITA 5.1), a standard for RACEway Interlink modules. RACEway crossbars may be combined on a RACEway Interlink module using ring, mesh, or tree topologies. RACEway used a parallel interconnect, as did early versions of RapidIO. Today RapidIO always means Serial RapidIO unless explicitly referred to as parallel RapidIO. RapidIO is a favorite interconnect in military applications and wireless base stations, where large data streams must be transported in a meshed configuration (such as DSP clusters) over short distances in real time without overhead. VMETRO, Norway, has recently introduced three high-performance VPX boards, all with RapidIO interconnects. They are used in applications such as distributed multiprocessing Intelligence, Surveillance, and Reconnaissance (ISR) or high-volume data traffic in real time. VMETRO currently offers four VPX and two VXS boards featuring Serial RapidIO. RapidIO European event The RapidIO Trade Association held its European Design Summit event on May 21, 2008 in Munich. Due to a local holiday, this event partially overlapped the WiMAX World EMEA, which was located only a few hundred meters/yards away. Both events suffered because they occurred during a two-week spring holiday period. Despite these problems, the event was very informative, including intensive interaction between attendees, presenters, and exhibitors. Presenters included Tom Cox, executive director of the RapidIO Trade Association (RTA); Thomas Nygaard, VMETRO Norway; as well as European representatives from subsidiaries of CommAgility, Freescale, IDT, Mercury Computer Systems, Fabric Embedded Tools, Texas Instruments, Tundra, and Xilinx. Tundra was the main sponsor for the Munich event. Tom Cox presented the status and roadmap of RapidIO. The current version of Serial RapidIO (V 2.0) was approved in June 2007. It does not specify physical interconnects, mechanics, or connectors. It is just a protocol standard, the only one of its kind approved on the international level (ISO/IEC 18372). Currently in many applications, a set of four RapidIO interconnects (x4) at 3.125 GHz is used and x1 channels are also popular. Cox announced that seven new members including GE Fanuc Intelligent Platforms, HDL Design House, Motorola, Nortel, Qualcomm, RMI Corporation, and Wintegra had recently joined the RTA.
Figure 1
Hannover gets industrial The Hannover Industrial Fair, held April 21-25, 2008 was opened by German chancellor Dr. Angela Merkel and Shinzo Abe, former prime minister of Japan as Japan was this year’s partner country. The fair comprises 10 sections, some of which alternate between odd and even years. Comparing this year’s fair with the equivalent structured event in 2006, there were about 30 percent more visitors looking at what 5,100 exhibitors from more than 60 countries had to show. In a survey, exhibitors reported about 15 to 20 percent more leads this time, totaling about 3.2 million sales leads. About 180,000 of the 200,000 visitors were professionals, which is 25 percent more than last time. Automotive applications and saving energy were among the most important topics. Figure 1 shows the Hannover Fair site (photo courtesy of Technology Consulting, Germany). There were various special events during the fair, including a job fair and robot competitions for high school students in a hall the size of several football fields. The young teams were busy making program and electronic changes to their robots between events. More than 20,000 young people participated in the robot competitions such as the RoboCup German Open, Youth Meets Industry, and TectoYou initiative events. Additionally, the WoMenPower conference was held for the fifth time. Dr. Ursula von der Leyen, Germany’s minister for family affairs, opened this conference within the industrial fair, which has the same goals as Women@CeBIT. (See the April 2008 issue of CompactPCI and AdvancedTCA Systems magazine.) Topics were equal opportunity for men and women and a Girl’s Day to interest women in technical education and inform them of company efforts to support women with children; this is because Germany has an extreme shortage of engineers and skilled workers in technical trades. Other special events included Industrial PC and Infrastructure, Robotics Academy, Automation Technology Live, Open Source Meets Industry, and many more. For more information, e-mail Hermann at hstrass@opensystems-publishing.com. VME and Critical Systems / August 2008 9
VITA 57 completes ANSI ballot while VITA 49 preps for ANSI VSO ANSI accreditation Accredited as a Standards Development Organization (SDO) in June 1993 by the American National Standards Institute (ANSI), the VITA Standards Organization (VSO) meets every two months to address vital embedded bus and board industry standards issues. Information on ANSI/VITA standards is available on the VITA website at www.vita.com. VSO study and working group activities Standards within the VSO may be initiated by a study group and developed by a working group. A study group requires the sponsorship of only one VSO member and is used to build interest in a standard. A working group requires the sponsorship of at least three VITA members, and the proposed work must fit within the defined scope of VITA’s accreditation with ANSI.
VITA 17.2 – Serial Front Panel Data Port (SFPDP) Channel Bonded Protocol Objective Increase the bandwidth for FPDP to include data rates of 2.5, 3.125, 4.25, and 6.25 and provide channel bonding for 2x, 4x, 6x, 8x, and 12x lanes.
E cast
Editor’s note: By the time you read this in August, the July VSO meeting will have taken place. Be sure to check out our online E-cast archives for the latest video and audio updates on VITA 41, 46, and 48. See www.opensystems-publishing.com/ecast.
to pass. The working group expects to be able to release the final document shortly. VITA 46 – VPX Objective Develop a 3U/6U 160 mm deep Eurocard module with a highdensity and high-performance connector capable of supporting both parallel and serial fabrics. Status The working group is reviewing proposals for optical connectors for 46.12. After review, the group agreed on a common configuration that will be supported by a number of connector manufacturers. VITA 47r2 – Revisions to ANSI/VITA 47, Environmental Requirements Objective Add new requirements for EMI/EMC classification of plug-in units.
Status Ralph Barrera, Curtiss-Wright Controls Embedded Computing (CWCEC), has returned as chair with Dean Holman, Mercury Computer Systems, as editor. A working group ballot was held during May, and the working group is reviewing ballot comments.
Status The working group is discussing whether to incorporate a requirement for EMI/EMC classification based on IEEE PAR-1688 (in development) as part of a new classification or as a separate dot specification.
VITA 41.6 – VXS 1X GbE Control Channel Layer Objective To define and assign 1X GbE signals for communication over signal sets currently defined as reserved for future use in VXS.0.
VITA 48 – Ruggedized Enhanced Design Implementation (REDI) Objective Define a general mechanical design implementation for circuit card assemblies that will enhance both their thermal performance and structural integrity.
Status Since VITA 41.6’s ANSI ballot had passed with 79 percent approval, the working group plans to review ballot comments and revise the draft as required. Kalpesh Sheth, DRS Codem Systems, has assumed the chair position of VITA 41.6 and Michael Monroe, Elma Bustronic Corporation, is editor.
Status Work is continuing on VITA 48.3, Liquid Cooling Inboard QDs, with discussions centering on the location of the manifold.
VITA 42 – XMC Objective Extend PMC to include serial fabrics.
VITA 49 – VRT Objective Develop a packet-based protocol for the digital transmission of radio signals to simplify IF distribution.
Status After 42.0 failed its ANSI ballot, a recirculation ballot was completed and has received the required number of affirmative ballots
Status The group is collaborating with several other groups and expects to submit their draft to the ANSI process soon.
10
VME and Critical Systems / August 2008
VITA 51 – Reliability Prediction Objective Develop a better method for predicting electronic module reliability. Status VITA 51.0 and 51.1 have completed an ANSI recirculation ballot. The ballot passed and the results have been submitted to ANSI for recognition. VITA 57 – FMC Objective Develop a mezzanine card standard optimized for FPGA use. Status VITA 57 has completed an ANSI ballot. The working group is reviewing all comments and revising the draft. A review of public review comments will be completed shortly also. VITA 58 – Electronic Module Standardization Objective Develop a form factor standard for ruggedized electronic modules. Status The working group has completed revision 0.6 of the draft and is holding a working group ballot. PDF – This column and the accompanying table are available at www.vmecritical.com/columns/vitastandards. For more information, e-mail John at techdir@vita.com.
VME and Critical Systems / August 2008 11
MAY MEETING HIGHLIGHTS Standard
Title
Status
reaffirmed
ANSI/VITA 1.0
VME64 Standards
Released
2002
ANSI/VITA 1.1
VME64 Extensions
Released
2003 2003
ANSI/VITA 1.3
9U x 400 mm Format
Released
ANSI/VITA 1.5
2eSST
Released
ANSI/VITA 1.6
Keying for Conduction-cooled VME
Released
ANSI/VITA 1.7
Increased Connector Current Level
Released
February 2004
ANSI/VITA 3
Board Level Live Insertion
Released
2002
IP Modules
Released
2002
ANSI/VITA 4.1
IP/I/O Mapping to VME64x
Released
2003
ANSI/VITA 5.1
RACEway Interlink
Released
2004
VITA 5.2
RACEway++
ANSI/VITA 6.0
SCSA
Withdrawn
August 2004 2002
ANSI/VITA 6.1
SCSA Extensions
Released
2003
ANSI/VITA 10
SKYchannel Packet Bus
Released
2002
Released
2002
ANSI/VITA 12
M-Modules
ANSI/VITA 13
Pin Assignments for HIC on VME
August 2004
2005
ANSI/VITA 4.0
Released
VME and Critical Systems edition
Withdrawn
ANSI/VITA 17.0
Front Panel Data Port
Released
ANSI/VITA 17.1
Serial Front Panel Data Port
Released
2004 February 2004
VITA 17.2
Serial Front Panel Data Port (SFPDP) Channel Bonded Protocol
Working Group
August 2008
VITA 19.0
BusNet Overview
Withdrawn
ANSI/VITA 19.1
BusNet MAC
Withdrawn
ANSI/VITA 19.2
BusNet LLC
Withdrawn
ANSI/VITA 20
Conduction-cooled PMC
Released
ANSI/VITA 23
VME64x Extensions for Physics
Released
ANSI/VITA 25
VISION
ANSI/VITA 26
Myrinet-on-VME
Released
ANSI/VITA 29
PC•MIP
Released
ANSI/VITA 30.0
2 mm Connector Practice on Euroboard
Released
ANSI/VITA 30.1
2 mm Conduction-cooled Euroboard
Released
VITA 30.2
Power Connector Equipment Practice
Released
April 2007
ANSI/VITA 31.1
GbE on VME64x Backplanes
Released
February 2004
ANSI/VITA 32
Processor PMC
Released
February 2004
VITA 34
A Scalable Electromechanical Architecture
ANSI/VITA 35
Pin Assignments for PMC to VME
VITA 36
PMC I/O Modules
ANSI/VITA 38
System Management on VME
Released
ANSI/VITA 39
PCI-X Aux. Std. for PMCs and PrPMCs
Released
February 2004
ANSI/VITA 40
Status Indicator Standard
Released
February 2004
2005
April 2005
Withdrawn 2003 2005
Working Group Released Withdrawn
April 2004 2005 April 2004
ANSI/VITA 41.0
VME Switched Serial (VXS)
Released
October 2006
ANSI/VITA 41.1
VXS InfiniBand Protocol Layer
Released
October 2006
Released
October 2006
Working Group
April 2006
ANSI/VITA 41.2
VXS RapidIO Protocol Layer
VITA 41.3
GbE
VITA 41.4
PCI Express
Working Group
April 2006
VITA 41.6
VXS GbE Control Plane
Working Group
August 2008
VITA 41.10
Live Insertion Requirements for VITA 41 Boards
Working Group
April 2006
VITA 41.11
Rear Transition Modules
Working Group
April 2006
VITA 42.0
Switched Mezzanine Card (XMC)
Working Group
August 2008
ANSI/VITA 42.1
Parallel RIO
Released
October 2006
ANSI/VITA 42.2
Serial RIO
Released
October 2006
ANSI/VITA 42.3
PCI Express
Released
October 2006
VITA 42.4
HyperTransport
Working Group
April 2005
12
VME and Critical Systems / August 2008
Standard
Title
Status
VITA 43S
Hot Swap NextGen Mezzanine
Inactive
Reaffirmed
VME and Critical Systems edition February 2004
VITA 45S
Serial VME
Canceled
April 2004
VITA 46.0
VPX
Working Group
February 2008
VITA 46.1
VMEbus Signal Mapping on VPX
Working Group
February 2008
VITA 46.3
Serial RapidIO on VITA 46
Working Group
October 2006 October 2006
VITA 46.4
PCIe Mapping & Advanced Switch Signal Mapping for VITA 46
Working Group
VITA 46.5
HyperTransport on VITA 46
Working Group
VITA 46.9
XMC and PMC User I/O Mapping for VITA 46
Working Group
VITA 46.12
Fibre Optic Interface on VPX
Working Group
ANSI/VITA 47
Env., Design and Const., Safety, and Qual. for Plug-in Units
Released
June 2006
VITA 47r1
Revisions to ANSI/VITA 47
Released
February 2008
VITA 47r2
Revisions to ANSI/VITA 47
Working Group
August 2008
VITA 48
Ruggedized Enhanced Design Implementation (REDI)
Working Group
August 2008
VITA 49
Digital Intermediate Frequency (IF)
Working Group
August 2008
VITA 50
Best Practices for Electronic Module Cooling
Inactive
December 2007
VITA 51
Reliability Prediction
Working Group
August 2008
VITA 52
Lead-free Practices
Working Group
October 2006
VITA 53
Market Surveillance
Study Group
October 2007
VITA 54
Embedded Platform Management Architecture (EPMA)
Inactive
August 2005
VITA 55
Virtual Streaming Protocol
VITA 56
Express Mezzanine Card (EMC)
VITA 57 VITA 58 VITA 59
August 2008
Working Group
June 2006
Inactive
October 2007
FMC (Mezzanine Standard for FPGA I/O)
Working Group
August 2008
Electronic Module Standardization
Working Group
August 2008
Rugged System-On-Module Express (RSE)
Working Group
For corrections or suggestions, contact Chris Ciufo, VME and Critical Systems magazine, at cciufo@opensystems-publishing.com.
VME and Critical Systems / August 2008 13
Software
Safety-critical software takes flight
Eclipse helps overcome development challenges in modern safety-critical IMA systems By Larry M. Kinnan Integrated Modular Avionics (IMA) platforms enable developers to integrate multiple discrete applications of different safety-criticality levels as defined by DO-178B onto a single processor through the use of time and space partitioning as defined by ARINC 653. This presents many unique challenges throughout the development cycle that must be addressed in order to successfully and cost effectively complete the project; these issues include the ability to transition the environment during development, integrate multiple vendors, support multiple connection methods, and ensure a partition-safe environment. These challenges occur in various phases of the development cycle, but they can be overcome by using both hardware- and software-based tools utilizing a common Integrated Development Environment (IDE) based on the open source Eclipse framework. Integrated Modular Avionics platforms have become the dominant implementation for avionics systems. These include everything from small general aviation projects running two or three applications to largescale commercial computing platforms running a large number of applications ranging from flight controls to wastewater management. These platforms support multiple applications of different safety-criticality levels as defined by DO-178B on a single CPU through the use of time and space partitioning as described and implemented by ARINC 653. The driving force behind replacing discrete Line Replaceable Units (LRUs) with timeand space-partitioned platforms is primarily to reduce the Size, Weight, and Power (SWaP) needs in aircraft such as the Boeing 787 Dreamliner Common Core System featuring 60+ applications. While IMA systems solve a number of operational and environmental problems for aircraft manufacturers, they present a number of challenges that span the entire development cycle. The typical development cycle for an IMA project will usually involve the development activities and roles defined in Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations (RTCA DO-297), as shown in Table 1. Individuals or teams will execute the specific roles to perform the development,
debug, and testing steps as described in DO-297. Each role has its own unique needs for debugging, analyzing, and testing, which lead to a number of challenges throughout the development cycle. These challenges include the ability to: 1. Transition from each phase of development in a cohesive manner 2. Integrate multiple vendors’ tools into an IDE framework in order to provide the necessary configuration management and testing tools required by DO-178B 3. Support multiple connection methods to target hardware to reduce costs and enhance flexibility 4. Ensure a partitioning-safe environment to support integration and DO-178B test for credit To overcome these challenges and support development roles with such divergent needs and requirements, the use of a common tool and development environment is key to making developers productive and successful. The Eclipse open source framework is a key element in this environment. Ability to transition environment during development In the past, developers of singleapplication avionics LRUs typically followed a development cycle similar in progression to that of an IMA platform.
Development Activity
DO-297 Defined Role
Board level bring up and check out
Platform provider
Operating System (OS) and driver development and debug
Platform provider
Individual application development and debug
Application developer(s)
Integration of multiple applications on the platform
System integrator
Table 1
14
VME and Critical Systems / August 2008
These platforms were then certified to a single DO-178B safety level. The initial hardware bring up, checkout, and testing were performed by the hardware engineering team and would usually employ hardware-assisted tools such as a JTAGbased In Circuit Emulator (ICE) or probe. These tools sometimes leave something to be desired once OS and driver bring up commence and eventually flow into application development and debug. This is even further exacerbated in a partitioned environment where some hardwarebased tools do not provide full partition awareness, effectively eliminating their usefulness in the application realm. This lack of awareness will add costs in both time and effort that could amount to as much as 20 percent of the overall project schedule based on experience, because without the base hardware and OS platform, applications developers cannot proceed with their work. The solution to this is a debugging IDE that covers this entire range of development phases through the use of hardwarebased tools using a fully partitioned OS debugging connection that has ARINC 653 awareness to allow full visibility into the system. A primary candidate is the Eclipse open-source framework coupled with JTAG-based debugging features for IMA systems. This provides a common “development cockpit” for all engineers involved in the project and reduces training and deployment costs as well as reducing time to productivity. While these reductions in time may only be 5 to 10 percent, this will produce a large return on investment in the later phases of the project since delays in later phases tends to be much more costly in time and overall costs. This is largely
because issues found in this phase tend to be extremely difficult to resolve without major design impacts and retesting effort. Additionally, having an IDE that can make use of different connection methodologies further extends the usability of the tool. This leverages the best of the Eclipse open-source framework while allowing vendors to provide their own value-add tools to the environment
their own IDE or command line interface that may or may not integrate with the other tools used in the development and test cycle, including configuration management, requirements management, and code generation. This incompatibility can lead to significant cost and churn since developers must learn multiple IDEs and are unable to leverage any commonality between the tools, their interfaces, and operation. These costs could be upwards of 15 percent of the overall project budget.
Ability to integrate multiple vendors As shown in Figure 1, the number of tools used in avionics development, debug, and test can be considerable. These tools are required in order to meet the requirements set in DO-178B and cannot be ignored if the project is destined to achieve some level of DO-178B safety certification. In the recent past, multiple vendors would typically supply these tools, each with
By employing an open-source framework like Eclipse’s, multiple vendors can integrate their tools into a common IDE as plug-ins. Eclipse takes advantage of this approach and allows a high level of integration with a large number of tools supplied by many vendors. Figure 2 shows the large number of tools available
Software Development Tools Market/User Need
Operations/Deployment
Requirements Definition
High-Level Design
Artisan IBM Rational Telelogic Tilcon PrismTech Zeligsoft
: Real Time Studio : System Tools : Rhapsody, Tau : Interface Dev. Suite : SPECTRA Tools : Component Enabler
: Certification Services : System Safety : TĂœV : Verocel Security : CygnaCom Solutions Safety
Subsystem Integration/Test : Cantata++ : Test Bed
IPL LDRA
Low-Level Design/Coding AICAS DDC-I Presagis Esterel Programming Research The MathWorks
System Integration/Test
Eclipse
Telelogic : DOORS IBM Rational : RequisitePro Verocel : VeroTrace
Simulation, Unit Test and Verification IPL LDRA Telelogic Vector Software Verocel Virtutech
: JAVA TOOLS : SCORE : VAPS : SCADE : QA C / MISRA-C / C++ : Simulink, Statemate
: Cantata++, AdaTest : Test Bed : Logiscope : VectorCAST : VeroCode : Simics
Code Creation/Generation/Debugging Eclipse integrations
Figure 1
Enormous Number of Tools Requirements Definition
Requirements Management
High-Level Design
UML Tools
Configuration Management Open Source Tools Prototyping Tools MMI Design Tools
Low-Level Design
Hardware Bring up
Telnet/Serial Shells
Hardware Trace Tools
JTAG Debugger Code Analyzers
Editors
Version Contro
Hardware Simulators
Data Tracing Tools
Multiple Debuggers
CPU Profilers
Systems Integration and Testing
Software Testing
Software Coding
Build Systems
Memory Leak Detectors
Unit Testing Tools
Code Browsers
Code Patching Framework
Code Coverage Tools
Figure 2
VME and Critical Systems / August 2008 15
Software and where in the development cycle they would normally be employed. Vendors who employ Eclipse and give the option of installing the entire framework plus plug-ins or installation of the plug-ins into an existing Eclipse framework offer flexibility for those who manage the development environment companywide. Ability to support multiple connection methods Past projects and their development environments typically did not provide any significant capability to choose how to connect to the target system in order to debug, test, and validate applications and system operation. The connection was typically limited to the available hardware port on the board; in a large number of cases, this was a JTAG connection. While JTAG offers significant capabilities for hardware test, low-level driver development, and test for credit capability, it sometimes leaves application developers lacking visibility into their applications due to the variety of programming languages and complexities of the code, especially as imposed by ARINC 653 time and space partitioning. Without this visibility, application developers may spend additional time trying to isolate specific application issues and bugs, delaying their ability to integrate their application into the full system. These delays tend to stack up and eventually delay project completion. The ability to exploit a target resident agent that operates in a time- and space-partition safe manner as an alternative to JTAG while still using the same IDE is the “best of all worlds” for the application developer and the development and test teams. The Eclipse framework serves as that common IDE while exploiting this extensible framework capability by supporting connections raging from JTAG, serial, and Ethernet as well as any number of custom connection plug-ins from vendors. By having full ARINC 653 partition awareness as well as multiple operation modes, these connection methodologies permit the development and debug of single partition-based applications through full system integration employing multiple application partitions. This saves developers multiple hours of setting up debugging scenarios. This savings in time reduces costs since developers are isolating and fixing bugs rather than fighting with the tools.
16
Safety-critical software takes flight Ensuring a partition-safe environment One challenge unique to the IMA environment is the notion of partition-safe debug and test. ARINC 653 specifies that the OS provides robust time and space partitioning; however, this can be disturbed by intrusive development and test tools, thereby limiting the usefulness and violating the constraints applied for the DO-178B test for credit. In the past, JTAG was not intrusive to the developer or tester since it operated at the hardware level and typically was used only to start and stop test scenarios; it would then extract the data for examination on a host IDE. Also without partitioning, the avionics system typically hosted a single application; so stopping the processor effectively halted all activity with the exception of external signals. As mentioned previously, it is highly desirable to leverage a common IDE for these activities while preserving partitioning both in time and space. Wind River’s Eclipse-based Workbench includes JTAG tools and provides this environment, along with an industry unique capability: a target agent that is completely OS and ARINC 653 aware, partition safe, and usable in the test for credit environment since it is a DO-178B qualified verification tool. The Agent for the Certified Environment (ACE) is a tool that runs on the deployed hardware platform and employs a communications method that interacts with the DO-178B qualified host-based tool to allow for partition-safe debug and OS data extraction using the certifiable system image on the target and qualified host tools. The agent is not part of the deployed binaries for the platform and is only loaded when external conditions such as “weight on wheels” are satisfied, or when a discrete signal indicates the platform is in test mode. This permits testing of the exact binaries that are eventually certified and deployed without contaminating them with test code, which is not permitted in DO-178B certified systems. These qualified tools allow for interaction and extraction of data from a target system. This capability is unique in the industry and provides users with flexibility and productivity in the development of certified (flight) system environments. This methodology coupled with JTAG and other connectivity technologies has already been used in aircraft certification projects. It is currently being used in test
VME and Critical Systems / August 2008
and integration of the Boeing 787 Common Core System running Wind River’s VxWorks 653 operating system. IMA is complex, but development shouldn’t be As one can see, an IMA provider faces many challenges. These challenges include the ability to transition the environment during development, integrate multiple vendors, support multiple connection methods, and ensure a partitionsafe environment. These challenges are compounded by the fact that many tools are required to complete the development, debug, and testing of such platforms as prescribed by DO-178B processes and guidelines. By utilizing an open-source IDE framework such as Eclipse, easy integration of multiple vendors’ tools and extremely flexible connection methods including ARINC 653 time- and space-partition safe tools can coexist. These tools help reduce initial development costs by reducing training needs, providing the benefits of wide-scale deployment of a common development “cockpit” throughout the organization. Additionally, by providing qualified verification tools, savings in time and productivity are exploited to reduce the expense associated with change throughout the entire IMA platform life cycle – the ultimate goal of employing IMA and ARINC 653. CS Larry M. Kinnan is senior avionics and safety-critical systems specialist at Wind River, where he has worked for more than nine years with a primary focus on safety-critical systems and ARINC 653 solutions. He has extensive experience with numerous aerospace programs such as 767 Tanker, Boeing 787, C130-AMP, and other commercial and military aircraft. Prior to joining Wind River, Larry was employed in the medical device design and development community where he was involved in safety-critical device design, development, and deployment. He can be reached at larry.kinnan@windriver.com. Wind River 330-677-2299 www.windriver.com
Software
Safety-critical software takes flight
Next-gen C++ API for avionics apps enhances application development By Troy Troshynski and Gabe Cook Avionics applications that require I/O access to aircraft data buses typically access these buses via the low-level C style API libraries supplied with bus interface modules, for example a MIL-STD-1553 or ARINC 429 PMC module. These low-level APIs are commonly focused on the hardware implementation of the interface module and therefore require the avionics application programmer to become very familiar with a particular hardware module. Additionally, these APIs do not provide inherent support for object-oriented software design or distributed multiprocess applications. Accordingly, a new generation of C++ high-level APIs has been designed to provide intuitive support for object-oriented, distributed applications. These C++ APIs allow the system programmer to focus on the avionics application and to more efficiently develop the avionics applications, while also supporting legacy applications. Critical airborne and ground-based aerospace software applications commonly require access to avionics data buses for communications with remote computing nodes, sensors, and actuators. In a typical avionics system, this interface is achieved by mounting an embedded interface module, for example a MIL-STD-1553 or ARINC 429 PMC module onto an embedded single board computer as shown in Figure 1.
Figure 1
applications and distributed computing paradigms and to be easily portable to multiple operating systems and the latest programming languages such as C# and Python. Most importantly, it has been designed to provide an intuitive programming interface that allows the applications developer to focus on the avionics application instead of the specifics of the interface hardware or the details of managing multiple distributed processes. Supporting state-of-the-art designs The new high-level API architecture’s primary software module is the API Core, which is based on a core Object Wrapper Layer (OWL) software module (see Figure 2). Additionally, the API Core provides an object-oriented encapsulation of the MIL-STD-1553 and ARINC 429 functions and features of the hardware interface module. The API Core is implemented in C++ and utilizes only standard external libraries, such as the Standard Template Library (STL). Usage of any operating system specific external libraries is strictly prohibited in order to allow the API Core to be easily ported to almost any operating system and Integrated Development Environment (IDE). When coupled with the newly
The embedded single board computer typically hosts an embedded RTOS and the application software. The applications software typically accesses the aircraft data bus through the lowlevel C style Applications Programming Interface (API) libraries supplied with the PMC interface modules. These low-level APIs are commonly focused on the hardware implementation of the data bus interface module and therefore require the avionics application programmer to become very familiar with and focused on the hardware implementation of the particular interface module being used. Additionally, because these low-level APIs are composed of C language functions, they do not inherently support Object Oriented (OO) programming and design methods, which are commonly used to efficiently build high quality, fault tolerant, and reusable applications software modules using C++. These APIs also do not provide inherent support for multiprocess, distributed applications, which are becoming more common as aerospace and avionics applications become increasingly complex. To support modern avionics applications designed using the latest OO design methodologies and programming languages, a new generation of high-level C++ APIs has been developed. This new API is designed to provide inherent support for multiprocess
Figure 2
VME and Critical Systems / August 2008 17
Software
Safety-critical software takes flight
added support for C++ compilation within many commonly used embedded operating systems (such as VxWorks, INTEGRITY, QNX, LynxOS, Linux, and Windows XP Embedded), this design requirement allows applications programmers to take advantage of the latest OO design methods to speed application development and ultimately reduce development and maintenance costs when compared to the usage of legacy C based procedural languages and methodologies. The new API Core technology also focuses the API on the data bus protocol for which it provides an interface (MIL-STD-1553 and ARINC 429) and shields the user from any details of the underlying hardware interface module. This results in a very intuitive programming interface that frees the applications programmer from the requirement to learn the low-level details of the interface hardware. Additionally, it promotes the development of applications that are independent of the underlying hardware, which increases flexibility and the potential future cost savings should newer and less expensive hardware become available. The sample code snippet below shows how a Bus Controller command sequence is built and executed using the new MIL-STD-1553 C++ API, demonstrating the hardware independence and intuitive nature of the new library. The implementation of similar functionality using existing low-level APIs could easily take double the lines of source code. // Create a new empty bus controller // configuration BusControllerConfig bcConfig; // Bus controller transfers are scheduled into // major and minor frames. BusControllerMajorFrameConfig* majorFrame = bcConfig.createMajorFrame(); // Let’s set the minor frame time to 250us. majorFrame->setMinorFrameTime(250); // Now we are going to set up a transfer. // Transfer A will be sent every minor frame. BusControllerBuffer* bufferA = bcConfig.createBuffer(1); BusControllerBufferedTransfer* transferA = bcConfig.createBCRTTransfer(bufferA); // Now we will create 3 minor frames and add the // transfers to them. BusControllerMinorFrameConfig* minorFrame1 = majorFrame->createMinorFrame(); BusControllerMinorFrameConfig* minorFrame2 = majorFrame->createMinorFrame(); // By adding this transfer to every minor frame, // it will be processed every 250us minorFrame1->addTransfer(transferA); minorFrame2->addTransfer(transferA); // Now we need to apply the configuration to the // physical bus controller. IBusController* busController = simulationChannel>configureBusController(bcConfig); // Now Start the BC busController->start();
18
VME and Critical Systems / August 2008
Due to the recently increasing popularity of new object-oriented programming languages such as C# (C Sharp) and Python, the API Core also addresses the need to provide inherent support for multiple languages. Because the new high-level API Core provides a C++ API that is simple and utilizes uniform method prototyping constructs, API designers are able to use the Simplified Wrapper and Interface Generator (SWIG) interface compiler to automatically generate extremely simple and thin software wrappers for the purpose of exporting APIs for other OO languages. In the past, when using existing low-level C based APIs, the task of creating an interface for another language was typically a time consuming and manual process that fell to the applications programmer and added to the overall cost of development. Distributed multiprocess applications Another common theme for modern MIL-STD-1553 and ARINC 429 applications and simulations is the use of multiprocess and distributed software architectures. When developing these types of applications using old-style APIs, the tedious tasks of managing shared object lifetimes, access to shared data, and the low-level communications between remote processes were left to the applications programmer and therefore added to project costs and impeded the developer’s focus on the avionics application. Thus, to provide more intuitive support for multiprocess (and possibly distributed) applications, new API Core technology includes a Remotable API Server consisting of a Server process and additional features and functions within the API Core to support Client operations. The purpose of the Remotable API service is to free the application developer from the tedious details of interprocess communications and to therefore reduce the cost of implementation while at the same time improving overall quality and performance characteristics of the application software. The Remotable API Server provides the functionality needed to make the avionics interface hardware APIs available simultaneously to multiple Client processes residing on the local host computer and on remote hosts available via a TCP/IP network. The details of the communications between the server and client processes are completely hidden from applications programmers, freeing them to focus on the avionics applications and not the synchronization and communications details of the host-to-host interactions. Additionally, platform-independent standard communications protocols (such as IIOP) are used to implement the internal communications interface between the Remotable API Server and remote clients. This allows new API architecture technology to seamlessly support distributed applications residing on multiple hosts using different operating systems. For example, a single distributed application could be spread across three hosts – two running Linux and one running Windows XP. Supporting legacy applications Due to the abundance of existing applications in service that are heavily based on legacy architectures that cannot support C++ and OO methodologies, the API Core was also designed to provide a complementing ANSI C Application Binary Interface (ABI). The C ABI allows the new API to also be effectively used in more traditional MIL-STD-1553 and ARINC 429 applications while at the same time providing some of the intuitive and hardware independent advantages of the C++ API. The C ABI is designed for binary compatibility, which allows subsequent
versions of the C ABI to be used by avionics applications without the requirement for the application to be rebuilt and redistributed. The C ABI is also modeled as a complement to the C++ API to allow applications programmers to easily move from one interface to the other. The code snippet shown below demonstrates how the object-oriented and intuitive nature of the C++ API has been reflected in the C ABI. // Create a new empty bus controller // configuration Owl1553_BusControllerConfig_new(&bcConfig); // Bus controller transfers are scheduled into // major and minor frames. Owl1553_BusControllerConfig_createMajorFrame(bcConfig, &majorFrame); // Let’s set the minor frame time to 250us. Owl1553_BusControllerMajorFrameConfig_ setMinorFrameTime(majorFrame, 250); // Now we are going to set up a transfer. Owl1553_BusControllerConfig_createBuffer(bcConfig, 1, &bufferA), “Could not create buffer.”); Owl1553_BusControllerConfig_createBCRTTransfer(bcConfig, bufferA, &transferA); // Now we will create a minor frame and add the // transfers to them. Owl1553_BusControllerMajorFrameConfig_ createMinorFrame(majorFrame, &minorFrame1);
Troy Troshynski is V.P. of Marketing and Product Development for AIM-USA, a leading manufacturer of MIL-STD-1553 and ARINC 429 avionics interface modules and software. Troy has more than eight years of experience working with high-speed avionics and data communications protocols and has worked in developing MIL-STD-1553, ARINC 429, and ARINC 664 real-time embedded software at both the device driver and application levels. Troy holds a Bachelor of Science degree in Physics from Doane College in Crete, NE and a Bachelor of Science degree in Electrical Engineering from Washington University in St. Louis, MO. He can be contacted at TroyT@aimusa-online.com. Gabe Cook is a Principal Software Engineer at AIM-USA, and he leads AIM-USA’s software development team in Omaha, NE. Gabe is the chief designer of the OWL software architecture. He has more than nine years of experience developing state-of-the-art test and simulation software applications utilizing object-oriented methodologies and languages on multiple operating systems and hardware platforms. Gabe holds a B.S. in Electrical Engineering and an MBA with an MIS emphasis from the University of Nebraska. He can be reached at GabeC@aimusa-online.com. AIM-USA 402-763-9644 www.aimusa-online.com
// By adding this transfer to every minor frame, // it will be processed every 250us Owl1553_BusControllerMinorFrameConfig_ addBufferedTransfer(minorFrame1, transferA, &newIndex); // Now we need to apply the configuration to the // physical bus controller. Owl1553_IChannelSim_configureBusController (simulationChannel, bcConfig,&busController); Owl1553_BusControllerConfig_delete(&bcConfig); // Start the simulated bus controller Owl1553_IBusController_start(busController, 0);
Taking avionics APIs into the future MIL-STD-1553 and ARINC 429 are widely used avionics data buses that can be found in many military and commercial aerospace applications where lifetimes can span decades. These data bus technologies have been proven to withstand the test of time and are still found to be central to many new aircraft and vehicle designs, ensuring their existence well into the future. As a result, there is a need for MIL-STD-1553 and ARINC 429 interface module programming interfaces to effectively and efficiently support both legacy and new system software design techniques that focus on object-oriented methods and multiprocess and distributed architectures. As a result, the systems programmer is freed from focusing on the specific hardware module and can concentrate on more efficient applications development. These were the primary design goals of AIM-USA’s software design team during the development of this new high-level software library architecture, designed to support multiple existing and new avionics applications on multiple hardware and operating systems platforms. CS VME and Critical Systems / August 2008 19
Technology
The size of VITA’s standards
When half isn’t exactly half: 3U vs. 6U VPX By Thomas Nygaard 3U VME, once a staple of the architecture, faded from the mainstream many years ago. However, the overall benefits of a 3U format have led architects back to 3U several times over the years, with the latest offering being VPX in both 3U and 6U formats. The trade-offs in choosing 3U are not as simple as “half” of 6U. Thomas explores some of the considerations in selecting a 3U versus 6U VPX format. The original version of VME created in the 1980s, which eventually was standardized as IEEE 1014-1987, called for both 3U and 6U form factors. The 3U format was popular initially, because there were enough pins on the single 96-pin P1 connector to support the popular 16-bit microprocessors of the era, and the board size was similar to contemporary standards such as STDbus, Multibus II (single), S-100, and others. However, over time the 3U VME format fell mostly out of favor as address and data bus widths increased, calling for more pins on the backplane. As 32-bit processors became the norm, the 6U format with both P1 and P2 connectors became the de facto size of choice for VME, dominating market offerings. As manufacturers embraced 6U VME more and more, they also realized the benefits of increased real estate for integrating more features on a single board, and created densely packed designs. In a revisit to 3U format, the CompactPCI specification defined in the 1990s brought a denser connector to the fray with more available pins. It began with a 3U format and later incorporated a 6U format. The 3U version was still somewhat limited by pin availability for I/O in some applications, but has seen fair success. As developers continue to ask for higher performance and functional density, the need for a 3U format hasn’t gone away. This is especially true in light of considerations such as Size, Weight, and Power (SWaP). Given the examples where 3U formats have proven viable, the architects of VME specifications have likewise stepped back to reevaluate a 3U format for their technology. Serial interconnects are now to the point where speed, reliability, and robustness make them a viable option for board-toboard interconnect. By eliminating the parallel bus constraint – and defining an
20
interconnect scheme leveraging new serial technologies such as Serial RapidIO, Ethernet, and PCI Express – pins can be freed up to support the right mix of data and control plane pins without sacrificing board-to-board bandwidth. This is exactly the approach called for in VPX, the ANSI/VITA 46 family of specifications. VPX has returned to defining both a 3U and 6U format, allowing designers to choose the best for their application. But the choice is not as simple as it seems on the surface. We learned in grade school that 3 is half of 6, but is 3U half of 6U?
“3U systems consume 150 percent of the total volume to deliver the same functional real estate for circuitry as an equivalent 6U system. This should cause many system designers to seriously consider a 6U solution when they thought they would be better off with 3U.“ Empirically half, but effectively less At first glance, a 3U board would appear to be half the size of a 6U board. Viewed from the front panel, this is very true: A 3U front panel is 132 mm long, while a 6U front panel is 265 mm long, and both are the same width. Based on this, it seems logical that a 3U board can con-
VME and Critical Systems / August 2008
tain 50 percent of the functionality of a 6U board. But a closer look is needed to evaluate the actual board area available to designers on each format. One consideration easy to overlook is the requirement for conduction cooling, with the wedgelocks on the vertical edges of the board. Many potential VPX applications such as UAVs indeed require conduction cooling. Also of consideration is the depth required for the backplane connectors, which consume a considerable amount of real estate. A simplified diagram is shown in Figure 1. The outline of a 3U printed circuit card is 100 x 160 mm, but with the keep-outs required for the connectors and conduction cooling wedgelocks, the “useful” area is approximately 78 x 148 mm, or 11,544 mm2. The same considerations applied to a 6U outline of 233 x 160 mm result in a useful area of 211 x 148 mm, or 31,228 mm2. With this reasoning, the mathematical ratio of available real estate on 3U compared to 6U is only 37 percent – not nearly half. This ratio can be further exacerbated by adding some common features: PMC/XMC sites – With connectors and mounting features, a mezzanine board consumes significant space on the underlying carrier card. Power supplies – Like many slot card standards, VPX boards take a common set of supply voltages and make onboard conversion to voltages needed to support today’s modern microprocessors, memory, networking chips, and other devices. These onboard converters are duplicated on each 3U board, just as on a 6U board. Large devices – While relatively easy to place on a 6U format, large parts such as microprocessors, host bridges, and FPGAs can consume large
portions of a 3U board very quickly. The placement of these devices can also cause constraints in placing and routing the rest of the board.
3U VPX in many cases. Why? Because 3U VPX can be the best choice in scenarios such as these:
Taking into account the points above, it is not unreasonable to argue that the effective area of 3U versus 6U is really closer to 33 percent. Thus, a system that could be implemented with three 6U boards would take as many as nine 3U boards, as shown in Figure 2. As depicted, this means that the 3U systems consume 150 percent of the total volume to deliver the same functional real estate for circuitry as an equivalent 6U system. This should cause many system designers to seriously consider a 6U solution when they thought they would be better off with 3U. The scale tips back at six From that perspective of only 33 percent effective useful area, it seems unlikely designers would ever choose 3U formats. But as mentioned earlier, there is a robust market for 3U formats, and programs like the U.S. Army’s FCS are specifying
Small systems – For systems comprised of six boards or fewer, the scale tips back in favor of 3U. The total size and weight of a system with fewer than six 3U boards – and the smaller subrack and backplane – is less than an equivalent 6U system. Rugged systems – Where systems are subjected to extremes of shock and vibration, 3U boards simply have less surface to flex and cause problems. Conduction-cooled systems – For systems where conduction cooling is the method used, 3U boards have shorter paths for heat to be conducted out, which makes it easier to get heat from the board to the cold plate than with 6U boards. Necessary functionality availability – 3U can in theory offer a finer functional granularity than 6U. For instance, if an application requires one Fibre Channel interface, one MIL-STD-1553 interface, and one Serial FPDP interface, there
Figure 1
Figure 2
would be no reason to use a 6U Fibre Channel board with three interfaces, a 6U MIL-STD-1553 board with three interfaces, and a 6U Serial FPDP board with three interfaces if each of these protocols were available in 3U with just a single interface. If an application needs only 1/3 of the functionality of a 6U board, building a system out of 3U boards would be the best choice. However, this argument only holds true in a perfect world where any conceivable function is readily available as a 3U board on the market. In practice, one will find that there are so many more boards to choose from in the 6U format that this easily will end up as the solution of choice. Upgrading an existing 3U-based system – The space for the system to go into may not be large enough to accommodate a system of 6U boards. So don’t think 6U can’t be used to build small systems The conclusion is that for designers who are aiming to implement a small system – especially a very rugged, conductioncooled system – the 3U format has its benefits. But as indicated, designers should keep in mind that for the smallest of systems, with six 3U boards or less, a 6U system with a small number of boards (three and up) may provide a more compact solution. The larger selection of 6U boards on the market also makes it more likely that a COTS solution can be found. The best news for designers is that with VPX, they have a choice of form factors – 3U or 6U – to provide the highest level of functional density for their application. CS Thomas Nygaard is CTO at VMETRO; he was one of the entrepreneurs who founded the company in 1986 and has been CTO since then. He has an MSc from the Norwegian University of Science and Technology in Trondheim. As his thesis, he developed the first VMEbus analyzer in the world, which later formed the basis for the foundation of VMETRO. He can be reached at tnygaard@vmetro.no. VMETRO 281-584-0728 www.vmetro.com
VME and Critical Systems / August 2008 21
Technology
The size of VITA’s standards
Making COMs rugged enough for harsh applications: VITA 59 opens the door for true standardization By Stephen Cunha By addressing shock and vibration, incorporating advanced cooling techniques, and taking both legacy and future technologies into consideration, ESMexpress-based VITA 59, also known as Rugged System-On-Module Express (RSE), brings time and cost savings to the design of mobile, mission-critical applications. And VITA 59 tackles the disparity within the existing COMs market to ensure interoperability among vendors.
Although they have been around for quite some time, ComputersOn-Modules (COMs) have failed to live up to the standards for which they were originally targeted. Prior to the COMs concept coming on the market in the early 2000s, designs were backplanebased, as in the case of CompactPCI and VME, or completely custom, either of which sapped an enormous amount of time and money in initial design phases and in the upkeep of system functionality. Developed shortly after the computerization of deeply remote and embedded system parts, COMs were designed to provide a streamlined, cost-effective method of implementing embedded computing solutions with minimal effort on the part of the developer. However, by 2002 COMs had quickly splintered into multiple variations without any type of standardization, thus negating the entire concept behind COMs: to provide modules that required less design and integration time and that provided an easy migration path for newer technologies. In fact, there are more than 50 variations of the concept currently available on the market. [Editor’s note: See www.smallformfactors.com/list.] One of the driving forces behind the resulting COM variations was that there really was no driving force. Blinded by the shortsighted notion of providing complete computers on a mezzanine card incorporating a standard CPU board and customization of the application-specific I/O executed on the carrier card, many companies failed to look long term and develop systems that designers could use in conjunction with one another. So, although designers can customize 100 percent of COM electronics within a short amount of time – since they only need to concern themselves with the carrier card and not the CPU – the lack of a standardized COMs product set precludes embedded designers from fully realizing the flexibility and cost savings advantages of COMs as a concept. Now, however, VITA 59’s Rugged System-On-Module Express (RSE) is opening the door, standardizing COMs and arming them with the advanced ruggedization so vital in critical environments. The standard also aims to ensure compatibility with legacy and future application road maps. What COMs do … and don’t do Since development occurs on the carrier board only, COMs (also known as Systems-On-Module or SOMs) cut system costs significantly, while optimizing time-to-market. Typically, COMs are used in small form factors less than 3U and are ubiquitous today because of an anticipated decrease in development costs. COMs do not require the infrastructure of a carrier board or the complete system to operate; therefore, intelligent mezzanine
22
VME and Critical Systems / August 2008
modules including processor PMCs, XMCs, or AMCs that do require these components are not considered COMs. Although COMs are widely used throughout embedded computing applications, only a very small portion of COMs products incorporate universal standards, and an even smaller number factors in modern serial communication structures. In addition, although COMs offer a cost-effective means of developing dense package computer systems for use in specialized applications requiring high volume, low power consumption, and small physical size, they typically do not hold up well in terms of critical rugged criteria such as temperature, shock, or vibration. In harsh environments, COMs essentially become ineffective. Enter the ESMexpress-based VITA 59 concept, in VITA development since January 2008, which provides rugged specifications for harsh environment, mobile, and mission-critical applications such as airplane, ship, and train control; mobile test systems; mobile medical equipment; industrial control systems; and more. A look inside VITA 59 As mentioned, VITA 59 offers designers the benefits of advanced ruggedization via advanced cooling techniques and other factors, along with road map compatibility and interoperability for legacy and future applications. Ruggedization ESMexpress, the technology behind VITA 59, addresses the shock, vibration, EMC requirements, and extreme temperatures typically found in rugged applications. In fact, the second draft of the spec, slated for review during this summer’s VSO meeting, specifies the following absolute minimum values: Shock: 15 g/11 ms (EN 60068-2-27) Bump: 10 g/16 ms (EN 60068-2-29) Vibration (sinusoidal): 1 g/10 Hz … 150 Hz (EN 60068-2-6) Additionally, during the standard’s development, the fanless cooling concept that enables power dissipation of up to 35 W and defines both conduction and convection cooling was a primary focus. The populated PCB, with a size of a mere 85 mm by 115 mm, as shown in Figure 1, is mounted into a frame with a final size of only 95 mm by 125 mm and is completely enclosed in an aluminum housing, which provides the added benefit of 100 percent EMC protection. Hermetically sealed on all six sides, the carrier card even shields the board-to-board connectors to the PCB.
interchangeability of ESMexpress modules. Legacy interfaces can also be implemented. Processor independence, combined with an industry-standard Samtec Q-Strip connector rated for military and railway applications, makes the CPUs interchangeable and scalable as well as flexible in regard to integrating further individual I/O using IP cores in an FPGA. Similar to COM designs, the FPGA in ESMexpress is added to the carrier board where needed and is controlled over a fast PCI Express link, ensuring a futureproof system.
Figure 1
Mounting does not involve any extra effort: The protruding edges of the PCB are clipped into the frame, so no screws are needed. A gap filler evens out possible PCB tolerances, and the high pressure caused by the safe joints between the housing and PCB supports the thermal connection of the components. The protruding PCB edges transport heat to the frame and then to the housing cover. The frame also moves the heat of the carrier board to the housing cover. Figure 2 shows the layering of the frame and PCB to facilitate the advanced cooling of the ESMexpress concept behind VITA 59: RSE.
For PCI Express, there are four single lane ports (4 x1) and one port that can be configured as 1 x16, 1 x8, 2 x4, or 2 x1, suitable for the connection of external high-end graphics. If only one single-lane port is needed, one of the two 120-pin connectors can be omitted entirely. Three 1 GbE (also as 10 GbE), eight USB, three SATA, SDVO, LVDS, HD audio, several utility signals, and the single 12 V power supply round out the connection ports. Standardized mechanical components, such as the frame and the heat sink, will be available on the market as standard products. It is also possible to use the module without a housing, depending on the application. Further, ESMexpress is developed to be compatible with all standard operating systems such as Windows, Linux, VxWorks, QNX, INTEGRITY, and so on, as a critical factor in the standard’s sustainability. ESMexpress is also designed for compatibility with ANSI-VITA 30.1 and ANSI-VITA 46. And finally, ESMexpress complies with the COM Express Basic Form Factor via an adapter board and has the five screw holes defined for COM Express, so ESMexpress modules can be used on COM Express carrier boards and vice versa. This is also an important factor in terms on interoperability and road maps, due to the number of systems that currently employ COM Express and could benefit from the added rugged attributes of VITA 59. With MEN Micro’s Intel Atom-based XM1 and the XM50, using Freescale’s MPC8548, the first two ESMexpress modules are now available on the market, offering designers proof of the operability of the new rugged COMs concept.
Figure 2
Resistance against shock and vibration is also key. For this, the module is not only fixed onto the carrier board using eight screws, but a connector specified for MIL and railway applications that supports differential signals up to 8 GHz (16 Gbps) is used. Road map compatibility and interoperability VITA 59: RSE also takes into consideration the road maps currently offered by many CPU manufacturers and the technological developments being sought by embedded designers. Therefore, the standard includes serial buses, not switched fabrics. Although the primary objective was to provide resistance to shock, vibration, EMC influences, and extreme temperature fluctuations, ESMexpress needed to support all current and future serial buses from PCI Express to Ethernet up to SATA and USB, since the embedded computing industry is moving away from switched fabrics in favor of serial technology. Accordingly, the electrical signals of ESMexpress are only defined for modern serial buses and are distributed on two 120-pin connectors with a fixed pin assignment and 0.5 mm pitch to guarantee complete
ESMexpress: Securing embedded systems VITA 59: RSE will enable designers to adhere to their future and legacy compatibility road maps and to fully realize the benefits of the COMs concept; no other COMs concept states specific requirements for ruggedization, as does VITA 59. The standard continues to progress, with the first ballot round of its second draft anticipated in autumn 2008. CS Stephen Cunha is vice president of MEN Micro Inc., headquartered in Ambler, Pa. Prior to joining MEN Micro, Stephen worked in sales and business development for Motorola’s embedded computing business for 12 years. He received multiple awards at Motorola and was twice awarded Motorola’s Pinnacle Award for Achievement. He holds a Bachelor of Science in Electrical Engineering from the University of Virginia. He can be reached at Stephen.Cunha@menmicro.com. MEN Micro Inc. 215-542-9575 www.menmicro.com VME and Critical Systems / August 2008 23
Hardware
CDC guards FPGAs, ASICs
Automated CDC verification protects complex electronic hardware from metastability failures By Michelle Lange It is imperative that engineers design modern avionics hardware (including ASICs or FPGAs) according to DO-254 requirements to ensure highly reliable, safety-critical designs. This includes designing hardware components that, while subject to metastability, will behave predictably. Additionally, proper verification is mandatory, and two methods are available: the tedious and often error-prone manual verification process, or the far superior method of using an automated Clock Domain Crossing (CDC) verification tool to ensure that all effects of metastability are correctly addressed to ensure safe design behavior. The complexity of FPGA and ASIC designs is becoming an issue for many military, aerospace, and other safety-critical industries. Integration of numerous components into a single System-On-Chip (SoC) is rapidly occurring in this segment. What was once a discrete component is now merely a block in a bigger system, but all within a single chip. Each of these blocks has its own function and likely its own clocking requirements. Because of this, the number of independent (and asynchronous) clock domains is on the rise. A 2004 study[1] showed that the average number of clock domains on a single device was between 5 and 10, and was projected to be greater than 15 by 2006. Today, this number is likely higher. This means that the probability of bugs due to CDC issues is also growing substantially. One of the most pervasive and insidious CDC problems is metastability, which occurs anytime a register connecting multiple clock domains temporarily goes into an indeterminate state, causing intermittent design failure. Metastability can be a dangerous thing in that it causes devices to fail intermittently in ways that are extremely difficult to diagnose. Failures, such as those caused by metastability, are unacceptable in safety-critical systems. However, if the problem is well understood, various techniques – both on the design and verification side – can address metastability, ensuring that safety-critical designs do not fail because of it. Automated tools designed specifically for CDC verification overcome the shortcomings of manual approaches and ensure comprehensive coverage – and resolution – of the metastability problem.
is intended to ensure hardware reliability for the purpose of flight safety. DO-254 defines a process that hardware vendors must follow to get their hardware certified for use in avionics systems. Certification authorities worldwide enforce its use for all in-flight hardware (that is, FPGA or ASIC designs). Verification is an important aspect of DO-254. Not only must Complex Electronic Hardware (CEH) designs be verified to ensure they meet the system requirements, but also any hardwarespecific aspects of a design that might impact proper operation must be verified. One hardware verification method that DO-254 mentions is Design Margin Analysis, which is defined as any method that “verifies that the design implementation satisfies its functional requirements given the variability of components.”[2] CDC fits within this category of analysis, as the variability of clock timing between independent domains can impact device function.
Failures due to metastability generally go undetected during simulation (which tests a chip’s logic functions) and static timing (which tests for timing within a single clock domain) because these verification methodologies do not consider potential bugs from CDC. Without explicit testing, these types of bugs are only caught in the actual hardware device in the lab or in the field. Catching them in the lab is expensive and time consuming, often prohibitively so. For DO-254 and other safety-critical projects, catching faulty operation in the field could have catastrophic results.
The problem with clock domain crossings A CDC signal is one that originates in one clock domain and is sampled by a register in another. Any ASIC or FPGA with more than one clock has CDC signals and must be designed and verified to ensure that it is free of CDC issues. Metastability is the term used to describe what happens
Designers are generally aware of the metastability problem and try to implement their designs to isolate the outputs of the metastable registers such that the metastable value cannot propagate into the rest of the design. For example, savvy designers add synchronizers between clock domains, create protocols for transferring data between domains, and try to
DO-254 and safety-critical design Document RTCA/DO-254, Design Assurance Guidance for Airborne Electronic Hardware (referred to herein as “DO-254”),
24
in digital circuits when the clock and data inputs of a flip-flop change values at approximately the same time. This leads to the flip-flop output oscillating and not settling to a value within the appropriate delay window, as shown in Figure 1. In this case, the output of the flip-flop is said to have “gone metastable.” This situation happens in every design containing multiple asynchronous clocks.
VME and Critical Systems / August 2008
Figure 1
avoid situations where data from multiple clock domains reconverge. However, as shown in Figure 2, it is quite easy to leave out needed synchronizers, or to place one incorrectly so that it does not work as expected. Even careful manual code reviews typically miss these problems. For example, reconvergence issues, one of the most common causes of metastability, are almost impossible to find through manual code reviews. Multiple signals are said to reconverge when they are transferred from one clock domain to another and are used together to perform some logical function. If these signals have an assumed relationship, then CDC reconvergence errors will occur. The effects of CDC issues can be highly data dependant and may only exhibit themselves in unusual situations when a combination of particular data values crosses the CDC boundary while the design is in a specific vulnerable state.
Figure 2
Designing to eliminate metastability Most companies have best practice requirements for designs containing multiple clock domains. These requirements often include placing specific clock synchronization schemes manually, naming CDC signals so they can be identified and reviewed, and ensuring the design is constructed so CDC signals are restricted to only subsections of the design. Unfortunately, even with strict design regulations, things can and do go wrong. For instance, a designer might fail to realize a signal is coming from a different clock domain and, thus, unintentionally violates a requirement. Conversely, a designer might realize a signal is coming from a different clock domain but chooses a synchronization scheme inappropriate for the design (that is, using individual synchronizer bits to synchronize a data bus, which results in corrupted data values in the real hardware). This is especially common when designs are reused and changes are made to an existing design. In this situation, it is easy for a designer to use signals without realizing they come from another domain, combine CDC signals into a state machine without considering the advancing/receding nature of synchronized control signals, and so on. Verifying DO-254 safety-critical designs After design has been completed, the next step is DO-254 verification, which can be executed manually or via an automated CDC verification tool. VME and Critical Systems / August 2008 25
Hardware Manual verification issues Manual verification methods can be quite problematic. For example, while an extensive manual code review could find structural issues, it would be tedious, time consuming, and error prone. In addition, manual reviews typically cannot ensure that transfer protocols are used correctly and rarely address reconvergence issues. Further, the reviewer can: Miss a signal altogether Identify a signal, but fail to realize it crosses to a different clock domain due to multiple fan-outs, misread a sending or receiving clock signal name, and so on Correctly identify all CDC signals, but fail to realize there is no synchronizer in place Identify all CDC signals and assure all synchronizers are in place, but not realize the synchronizer is incorrect (that is, synchronizing multiple bits of a data bus using independent synchronizers, and so on) Identify that all CDC signals and synchronizers are correct, but miss the fact that combinational logic placed in or around the synchronizer invalidates the timing requirements of the synchronizer To complicate matters, DO-254 projects require that verification and design be done independently. This is good in many regards, but when it comes to safetycritical, multi-clock designs, it is not. Verification engineers generally are not as well versed in design as the designers themselves and often do not recognize CDC issues. Automating CDC verification Even if the verification team does recognize the problems associated with CDC, verifying metastability effects by hand is extremely difficult and error prone, as there can be literally hundreds or even thousands of CDC signals. Therefore, companies benefit greatly by using an automated tool designed specifically for CDC verification to bridge the knowledge gap between design and verification teams and to ensure comprehensive coverage of these issues. A comprehensive CDC verification tool, such as that offered by the Mentor Graphics 0-In CDC tool, must include the following three capabilities. 1. Perform a structural analysis. This is most effectively done on the RTL code to identify and analyze all signals’ cross-
26
CDC guards FPGAs, ASICs ing clock domains and determine if their synchronization schemes are present and correct and to: Identify the clock structure used in the design (clock domains, clock gating, dividers, and so on) Identify all CDC signals in the design Determine the synchronization scheme (if any) used on the signals Check that each synchronization structure is implemented and used correctly While the process is automated, the user has the ability to guide the tool by providing additional information on clock groups, preferred synchronization types, exceptions, and many other options. If a problem is identified in the structural synchronization, it can be debugged using an interactive environment specifically designed to simplify working with CDC signals. 2. Verify transfer protocols. The automated CDC verification tool assures that the synchronization schemes are used correctly, by monitoring and verifying that protocols are being followed during simulation. This is accomplished via the use of advanced assertion-based verification techniques. Using the information extracted from the design during structural verification, CDC protocol monitors are automatically created. The monitors contain assertions that check whether the appropriate CDC protocol is followed at all times, regardless of the current clock relationship. The assertions do not require that a violation causes simulation to fail. Any violation during simulation is automatically captured by the automated CDC verification tool, allowing the designer to easily debug the problem. Additionally, the monitors capture critical coverage information, allowing the verification team to quantify the quality of the CDC verification. When running multiple simulations, the results can be concatenated together, allowing any coverage holes in the CDC testing to be exposed. 3. Globally check for reconvergence. This is most effectively done by injecting the effects of potential metastability into the simulation environment and determining how the design will react. 0-In CDC includes the CDC-FX technology, which integrates with existing simulation environments to introduce metastability effects in order to reproduce the same
VME and Critical Systems / August 2008
variable delay behavior that would occur in the final hardware. These metastability injectors are automatically placed into existing RTL simulations and on all CDC paths – even those that do not use structured synchronizers. These injectors pseudo-randomly inject the effects of metastability into CDC signals only at appropriate times when metastability could occur in hardware. If the design is not tolerant of these effects, due to reconvergent CDC paths, a functional error will be stimulated, which can be debugged using traditional techniques. Reducing the risk of metastability The number of independent clock domains is on the rise, resulting in a higher risk of metastability. Metastability is a dangerous occurrence in safety-critical designs. Designers typically understand the process, but addressing all aspects of metastability manually is very difficult. Thus, thorough verification specifically targeted at the CDC problem is imperative to ensure safe device operation. Automated CDC verification has been available for years and has been proven on thousands of industry designs. Thus, the problem of undetected metastability bugs can be solved, but only if it is understood and addressed during verification. Every multiclock, safety-critical design, especially those subject to DO-254 compliance, should specifically run automated CDC checking – as opposed to the less-effective manual verification method – as part of a thorough verification process. CS References
[1] 2004 IC/ASIC Functional Verification Study, Collett International Research. Used with permission. [2] RTCA/DO-254 “Design Assurance Guidance for Airborne Electronic Hardware” section 6.3.
Michelle Lange, currently a program manager specializing in DO-254 projects at Mentor Graphics Corporation, has held various technical and business-oriented roles in the field of Electronic Design Automation (EDA) for more than 19 years. She holds a BSEE from the University of Portland and an MBA from the University of Phoenix. She can be contacted at michelle_lange@mentor.com. Mentor Graphics Corporation 503-685-1768 www.mentor.com
ES-SCAN software simplifies EMI measurements
Join the counter-culture: Static analysis on OS X
If your VME equipment operates anywhere near commercial or civilian systems, chances are you’re going to have to deal with FCC EMI/EMC compliance. When systems are designed from the start with EMI as a design criterion, compliance testing can go more smoothly. To do this, designers need test receivers set up and running at the earliest stages of product development. But testers are only one thing; you also need easyto-use software to automate the process and save time. Designed for use with the company’s R&SESP13 and R&SESP17 receivers, Rohde&Schwarz ES-SCAN software can be operated with a single mouse click, invoking preconfigured test setups aimed at commercial EMC standards. Typical configurations include antenna transducer factors, peak value recording, and graphical/numeric data display. User-defined thresholds can be set, as well as detected (or suspected) interference frequencies – making measurements in those regions literally push-button easy. Other nice features include marker functions, automatic peak search, automatic data reduction, and multiple types of output reports. The software runs under WinXP, has interface options for National Instruments’ VISA software, and includes USB, Ethernet, or IEEE-488 hardware connections. Rohde&Schwarz • www.rsa.rohde-schwarz.com • RSC# 37690
OK, so you’ve got your 5G iPod, your third-gen iPhone, and a new Core 2 Duo Mac running OS X 10.5. Oh, yes – and you’ve got a target system destined for a 19-inch VME rack. It’d be a real bummer to have to spark up that old Windows XP machine just to verify some source code. Well, you don’t have to. Check out GrammaTech’s CodeSonar 3.1 Enterprise, now available for desktop and server versions of Apple’s Mac OS X operating system. You can surely get on your “inner Steve” (Jobs) with this product. Designed to identify complex programming bugs via whole-program, interprocedural analysis, CodeSonar 3.1 intentionally targets code destined for safety-critical applications. The tool uses an interprocedural, context-, path-, and object-sensitive analysis method. It first does a regular code build, then instead of creating object code, it creates an abstract representation of the program, which is then symbolically executed via dataflow analysis. Infeasible paths are pruned, false positives suppressed, and the results yield anomalies for the programmer to check. The tool works with the existing source and build system, “watches” how you compile code, and “learns” what it needs in order to perform an analysis. CodeSonar can work on the entire program or on partial programs, and is ideal for zeroing in on buffer overruns or format string vulnerabilities – two common exploits in safety-critical systems. There are more than 20 other code checks besides these, and the tool presents results in HTML. GrammaTech • www.grammatech.com • RSC# 37693
Bye-bye, build audits; hello, on-the-fly debug Statistics from analysts much smarter than us report that up to 70 percent of design time is consumed in writing, debugging, debugging, and debugging software. You get the idea. So any kind of tool that contracts this iterative process – especially if it can help during the coding part of the process – might be a real money saver. We don’t care if you’re designing VME systems or coding the next PS3 game. The automated source code analysis tool called Insight from Klocwork specifically targets mission-critical systems, making it perfect for VME/VXS/VPX board-based designs. Of particular importance is that this desktop tool is intended for use by the developer during local build, instead of providing an after-the-fact audit build report. Some of the tricks in Insight have spawned patents, including certain static analysis techniques and system-level collaboration to track bug fixes. The list of features is too numerous to describe here, but highlights include: identification and analysis of critical and security bugs (handy in mission-critical systems); IDE-based code analysis (no need to exit your favorite tool); detailed software architecture visualization; user-defined style or path analysis checkers; bug tracking and reporting – locally or team-based. We are impressed with the potential of Klocwork’s Insight. (Tell us if you have any experience with this tool. We’d love to hear from you at cciufo@opensystems-publishing.com.) Klocwork • www.klocwork.com • RSC# 36761
Save time: Verify PCIe systems With PCI Express now the de facto on- and between-board “bus,” it’s more important than ever to debug signals and protocols. And with now-available high I/O VPX boards, there will be more PCIe lanes than ever traveling around a VME chassis; that’s why it’s critical to make sure those PCIe lanes are working correctly. Mentor Graphics’ PCI Express verification combo consists of the Veloce family of ICE accelerator devices plus the iSolve PCI Express adapter platform. Together, they can verify PCI Express operation, signaling, and I/O connectivity, and even provide real-world PCIe stimulus to in-design VME systems. The typical solution consists of a PCIe-equipped PC, the iSolve adapter, and a Veloce hardware accelerated PCIe ICE. Together, the platform delivers a 1,000 to 10,000x speed improvement over software-only simulation, which “saves weeks or months of regression time.” The solution can identify and fix corner-case bugs in hardware (processor interfaces, bridges, I/O devices, and board traces), and is compliant to both PCIe 1.1 and 2.0. The platform supports all architectures – endpoint, root complex, switch, and bridge – as well as x1, x2, x4, and x8 lanes. Protocols for memory, I/O, configuration, and message transactions are tested or emulated, and interleaved packets across all lanes can be configured. iSolve is flexible, in that it can be configured either for upstream traffic (toward the root complex) or downstream to the endpoint (with emulation in the opposite direction). Mentor Graphics www.mentor.com RSC# 37691, 37692
Editor’s Choice Products are drawn from OSP’s product database and press releases. Vendors may add their new products to our website at www.opensystems-publishing.com/np and submit press releases at www.opensystems-publishing.com/news/submit. OSP reserves the right to publish products based on editors’ discretion alone, and does not guarantee publication of any product entries.
VME and Critical Systems / August 2008 27
By Cliff Witte
A/D DIGITIZer PMc 4DSP Website: www.4dsp.com Model: AD484
rSc no: 36144
Quad 14-bit, 125 MSps A/D digitizer PMC (Virtex-4 FX and SX/LX) with optical transceivers • Four 14-bit, 125 MSps A/D channels • Custom external clock and trigger inputs • Dual Virtex-4 FX and LX/SX FPGA architecture • QDR2 SRAM and DDR2 SDRAM • PCI-X 64-bit 133/66 MHz • Serial FPDP with optical transceivers
A COTS software component providing highperformance radar scan conversion capability • Radar scan conversion (PPI and A-Scan) using Windows and Linux • Easy-to-use software modules to add into existing applications • Low-cost, high-performance solutions • Accepts primary radar video from hardware, network, or disk recording • Scan converts in real-time to one or more display windows • PPI and A-Scan display formats at resolutions up to 1,920 x 1,200 • Allows underlay and overlay graphics using advanced software-based rendering • Flexible toolkit is compatible with radar processing library • Real-time fading, multi-channels, multiple colors, advanced display processing options
rUGGeD GrAPHIcS cOnTrOL cArD
curtiss-Wright controls embedded computing Website: www.cwcembedded.com Model: nvIDIA G73M rSc no: 37436
The zero slot feature uses the thickness of the PCB plus special low-profile fans to reduce the rear dimension to the legal PCI height • Front side clearance is less than the legal PMC height for position two • Matched length, differentially routed, impedance controlled rear I/O from Pn4 • PMC bezel I/O through the PCIe rear port • Tsi384 bridge for higher performance than PEX-based designs • 32- or 64-bit operation at 33, 66, 100, or 133 MHz • Supports DMA and interrupts • LEDs for power supply status, PCI Express lane status, PMC installed
vMe64x DUAL PrPMc cArrIer cArD
extreme engineering Solutions Website: www.xes-inc.com Model: Xchange4000
rSc no: 36996
vMe neTWOrK STOrAGe BLADe AcT/Technico Website: www.acttechnico.com Model: vMe rAIDStor
rSc no: 36999
A single-slot 6U VME network attached storage blade that provides the same automatic, transparent data replication and re-sync of traditional box-level RAID storage modules • Automatic fail over, drive to drive or blade to blade • Automatic and transparent duplication of the data across the primary and secondary storage blades • Drive level front-panel hot swap • RAID 0, 1, 0+1, and 1+1 configurable – no hardware to exchange • Network management without impact to toplevel application • Smallest RAID footprint in the industry
A ruggedized graphics display control XMC card • Up to 512 MB DDR2 SDRAM dedicated graphics memory • Dual independent analog and digital video output • Analog outputs support separate H and V, composite or sync-on-red/green/blue • Video integrity monitoring for display freeze detection • Available in air- and conduction-cooled ruggedization levels • Flexible I/O via PN6, PN4, or front panel • Graphics software suite with hardware-accelerated X11 server, OpenGL ES 2.0, SC 1.0, video capture driver • Supports VxWorks 6.x, Linux, Windows XP • Supports PowerPC and x86
rSc no: 35967
rSc no: 37021
rADAr ScAn cOnverSIOn SOFTWAre
GAO IDE for ARM Development Tools Suite B • An integrated development environment • Project management facility • Integrated source-code editor • GNU compilers, assembler, and linker • GNU ANSI C library • Also supports ARM build tools • Source-level debugger • ARM instruction set simulator
cambridge Pixel Website: www.cambridgepixel.com Model: SPx Scan conversion rSc no: 36406
PCI Express carrier/adapter for PMC • Integrated power supplies – up to 64 W without a power cable • Options for cooling cutout or fans • Fans can be mounted without using a second slot •
28
ArM DeveLOPMenT envIrOnMenT GAO Tek Inc. Website: www.gaotek.com Model: GAO IDe
PcI eXPreSS cArrIer Dynamic engineering Website: www.dyneng.com Model: PcIeBPMcX1
6U VME64x carrier card with dual PrPMC sites • Supports VME64, VME64x, and 2eSST • Conduction cooled or air cooled • 32-bit/64-bit local PCI operation bus • 33 MHz or 66 MHz PCI operation • 66 MHz or 100 MHz PCI-X operation • P4V0-64 and P4V2-64ac I/O routing • VITA 31.1 GbE backplanes • Ideal for high-bandwidth applications • Includes a local +3.3 V power supply so backplane +3.3 V is not required
VME and Critical Systems / August 2008
For more information, enter the product’s RSC number at www.vmecritical.com/rsc
VME ARBITRARY WAVEFORM GENERATOR
Highland Technology, Inc. Website: www.HighlandTechnology.com Model: V346 RSC No: 37060
ules • PCI Express I/O sites (VITA 42.3) deliver >600 MBps to CPU memory • Integrated timing and triggering support for I/O includes optional GPS-disciplined clock • Supports Innovative X3 and X5 I/O module features for private data channels, triggering, and timing features • Boots from SATA or USB flash • Optional GPS module support • AC or 12 VDC operation
SOFTWARE TOOL CHAIN
Aonix Website: www.aonix.com Model: PERC Pico 1.1 RSC No: 37426
VITA 41 DIGITIZER BOARD An eight-channel 32 MHz VME arbitrary waveform generator • Channel-channel modulation allows arbitrary AM, FM, PM, PWM, and summing of anything with anything • Multiple modules can synchronize for an unlimited number of channels of synchronized waveform generation • Selectable output frequency ranges, ±32 MHz with 15 MHz resolution to ±250 KHz with 166 uHz resolution • DC coupled 50-ohm outputs to ±5.12 V • Programmable offset allows wave+offset or direct DC DAC functionality • Simulates polyphase, transducers or quadrature encoders, complex switch-mode H-bridges, calibrated jitter
CONDUCTION-COOLED ATR
Hybricon Corporation Website: www.hybricon.com Model: Forced Air CondATR RSC No: 36173
TEK Microsystems, Inc. Website: www.tekmicro.com Model: Neptune-V5 RSC No: 37678
6U VITA 41-compliant dual channel high-speed digitizer board • Designed for demanding sensor-processing applications across a range of environments • Customer choice of three Xilinx Virtex-5 FPGAs to provide maximum highbandwidth processing and system configuration flexibility: Virtex-5 LXT for high-performance logic with low-power serial connectivity; Virtex-5 SXT – Optimized for DSP and memory-intensive applications with low-power serial connectivity; or Virtex-5 FXT – Optimized for embedded processing and memory-intensive applications with highest-speed serial connectivity • Full ruggedization designed in, providing full support for harsh environments
The latest release of the PERC Pico tool chain with real-time memory analysis tools for Java programmers • Eclipse IDE enables safe and scalable approach to low-level Java code • Based on an emerging Java Specification Request (JSR-302) for development of hard real-time safety-critical code • Offers developers a new memory-use analysis tool • Developers of real-time Java systems can statically analyze memory requirements and the memory footprint implications associated with source code changes without resorting to traditional test and debug methods • Provides new Eclipse plug-ins for building, launching, and debugging PERC Pico applications • New debug facility automatically translates executable symbol names in a PERC Pico application to the Java names shown in the Eclipse editor
Forced air conduction-cooled ATR • Top load 6U dip brazed card cage • Eight-slot customer specific VME64x backplane • Sealed internal area offering protection against foreign matter • Front-to-rear airflow over folded fin stock • 400 W MIL-STD-704E conduction-cooled power supply • 28 V input system monitoring • Top access panel with captive hardware • Front I/O panel • Provisions to mount rugged slides
COMPACT RUGGEDIZED CARRIER CARD
Innovative Integration Website: www.innovative-dsp.com Model: SBC-ComEx RSC No: 36881
A compact, stand-alone, and rugged dual XMC slot, intelligent carrier card • Combines industry standard COM Express CPU module and dual XMC modules • Scalable CPU performance from Celeron to dual-core Pentium with up to 4 GB memory • Small form factor: 250 mm x 170 mm • Able to operate diskless and headless • Runs Windows or Linux applications • Configurable I/O uses standard XMC I/O modules • Add anything from RF receivers to industrial control mod-
VME and Critical Systems / August 2008 29
By Chris A. Ciufo, Editor
New processors: Choose wisely After Apple announced their intention to buy PowerPC processor vendor P.A. Semi back in April, rumors began swirling that the big guns at the DoD would swagger in and block the acquisition. Armchair warriors, pundits, and vendors responded with indignation, fully expecting Apple to pull the device from the market while keeping the IP and patents to itself. Although Apple’s switch to Intel Core Duo family devices brilliantly moved Apple into the computer mainstream (and away from the too-hip Jobs Faithful), the company still generates more than half of its business from portable, low-power doodads like iPhones, iPods, and the downloaded music and movies that fill these devices. Apple loves to control its hardware platforms, and P.A. Semi gives them a chance to revert to that model in handhelds. As well, PC industry experts are lauding the iPhone as the right way to do a UMPC – so Apple has the chance to create yet another market and own it (sorry, Microsoft). We’re talking high stakes here, folks, and the P.A. Semi device could well be the silver bullet Jobs and Co. need. But in our board-based embedded VME industry, P.A. Semi’s PA6T-1682M processor offered power consumption in the dim lightbulb range compared to the solar flares of Freescale’s MPC744x and MPC8641x CPUs. The road map for these redhot devices is what drove numerous VME specs, including the liquid cooling language of VITA 48 (REDI). But with P.A. Semi’s processor, suddenly some VME vendors (Curtiss-Wright, Varisys, Mercury Computer Systems, Extreme Engineering, Themis, and others) announced plans to release low-wattage PowerPC SBCs and PMCs. And I’m certain many more had designs in-process ready to announce. With so many of these boards earmarked for defense applications, everyone expected Apple’s acquisition to catalyze a return to the days of “blue helicopters landing in the parking lot out front of Fairchild and shutting the place down” while invoking the Cold War era – now antique and quaint – DX/DO rating system. Yeah, right. Long gone are the days when the DoD was the biggest IC customer before the invention of the PC and cell phone, 1
and had the clout to mandate that a supplier process MIL-SPEC backlog first as a matter of national security1. Recall that we’re talking about Apple’s Steve Jobs, the guy who essentially flipped the bird to the swimming-in-big-bucks-lawyers, multi-billion dollar industries represented by the MPAA and the RIAA. Not even Microsoft, Amazon, nor AOL were able to crack the market to begin selling 99-cent songs on proprietary software called iTunes and later demonize DRM copy protection. So it makes me chuckle to think that old Steve would be concerned by the 0.5 percent IC market share of the DoD and their possible threat to Apple (alleged back-dated stock options notwithstanding). With no DX/DO nor FAR flow-down contracts in a COTS world, Mr. Jobs is going to do what’s best for Apple. Ain’t no way – short of a trip to Gitmo in Cuba – that Apple is going to buckle. So if you’re expecting a miracle, I suggest sticking with AMD, ARM, Intel, or Freescale CPUs. UPDATE: At press time, we were unable to make contact with the right PAO at the DoD to get the official word on this situation. But accord according to Bret Farnum, VP of sales and marketing at P.A. Semi customer Extreme Engineering (www.xes-inc.com), Apple has apparently worked out a deal that will make an adequate supply of pro processors available for “at least three years.” Since they’re fabbed by longtime mil supporter Texas Instruments, who has a well-documented life-cycle policy, one can speculate that Apple is merely accepting DoD forecasts and executing a lifetime buy with TI. It’s also possible that one of the many aftermarket suppliers like Rochester or Lansdale – or even the DoD’s own DMEA or GEM Program – have cut some sort of a life-of-type buy arrangement. If true, mil programs and VME vendors using P.A. Semi devices have dodged a bullet. It just means that you should be cogni cognizant of the upside potential and the downside risk, no matter how compelling the product, when designing in new processors from companies like Ambric, Innovasic, MathStar (no longer making ICs or systems), picoChip, Tilera, Transmeta (now IP only), and others. If the product is that (ahem!) hot, someone else may think so, too.
Chris A. Ciufo cciufo@opensystems-publishing.com
Full disclosure: As the military account manager for companies like Hughes Aircraft and TRW while employed at AMD long ago, I recall at least one occasion where the DoD actually did require us to priority process their backlog for Class S bit slice devices. Back then, when the Air Force issued the threats, we snapped to attention.
30
VME and Critical Systems / August 2008
RSC# 32 @ www.vmecritical.com/rsc