Arrive on Time with X-ES. - OpenSystems Media

FRUSTRATED BY DELAYS?<strong>Arrive</strong> on Time with X-ES.Is your embedded computing vendor causing frustrating delays? At X-ES,we know the importance of keeping your project on schedule. Decisionson custom requests are made quickly. Proposals are responded topromptly. X-ES customer support provides direct access to engineeringexpertise and fast, accurate answers. With a proven history of meeting ourcustomers’ aggressive schedules, X-ES is the choice to eliminate delays.Keeping your project on time. That’s Extreme.Extreme Engineering Solutions608.833.1155 www.xes-inc.com

SuMMEr 2012 / VOluME 16 NuMbEr 2www.advancedtca-systems.com@cpci_atcaOn the coverCOTS management building blocks forAdvancedTCA: Proven over the first decadeBy Mark Overgaard,Pigeon Point Systems» p.11Hardware platform management has become a criticalenabler of the continuing growth of the ATCA market. COTSmanagement controllers, such as Pigeon Point Systems’BMR-A2F board management core (top right) and ShMM-700Rshelf management controller (bottom left), are an effectiveway to realize the mandatory management controllers in ATCAboards and shelves, supporting the needs of Tier 1 TEMs forstable, interoperable, cost-effective platforms.» p.15Adaptable AdvancedTCAShelf Manager FirmwareBy Michael Thompson,Pentair Technical Products(Schroff)5 Editor’s Foreword / Brandon LewisHPM and managing the “9s”7 Network Intelligence / Curt SchwadererArchitecture, modeling, coordination, andsynchronization of multicore applications10 4G Focus / Mike DemlerHow one TEM leverages ATCAHardware Platform ManagementBy Jari Ruohonen, Nokia SiemensNetworks» p.19Special Advertising Feature:Interview with Thomas Kastner,Chief Architect x86 Software,Advantech Networks &» p.22 Communications GroupBase stations-on-a-chip deliver the lowercost per bit promise of 4G LTE networksAdvertiser Index22 Advantech Corporation Interview with Thomas Kastner, Chief Architect x86Software24 Annapolis Micro Systems, Inc. High performance signal and data processing20 ATP Electronics ATP industrial grade flash products and DRAMmodules3 ELMA Electronic So fast. So cool.9 Excalibur Systems, Inc. Ready for the unexpected?x2 Extreme Engineering Solutions Frustrated by delays?23 GE Intelligent Platforms, Inc. Enabling and securing the connected warfighter6 MEN Micro Elektronik GmbH CompactPCI goes serial13 N.A.T. GmbH The heart of your MTCA system21 Pigeon Point Systems Celebrating 10 years of delivering xTCAmanagement solutions17 Sunrich Technology Quality + reliability customization service16 VEROTEC Electronics Packaging TecSYS cPCI development platforms12 Wolf Industrial Systems, Inc. Modular video graphic solutions® 2012 OpenSystems Media® CompactPCI, PICMG, PICMG, ATCA, AdvancedTCA, MicroTCA, and their logos are registered trademarks of PICMG.TMAdvancedMC and xTCA are trademarks of PICMG.© 2012 CompactPCI AdvancedTCA & MicroTCA SystemsAll registered brands and trademarks in CompactPCI AdvancedTCA & MicroTCA Systems are property of their respective owners. Member since 19984 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systemsenviroink.indd 110/1/08 10:44:38 AM

CompactPCI ®Goes SerialCompactPCI, Advanced & MicroTCA Systems Editorial/Production StaffJoe Pavlat, Editorial Directorjpavlat@opensystemsmedia.comMike Demler, Technology Editormdemler@opensystemsmedia.comCurt Schwaderer, Technology Editorcschwaderer@opensystemsmedia.comBrandon Lewis, Associate Editorblewis@opensystemsmedia.comDavid Diomede, Art Directorddiomede@opensystemsmedia.comSales Group PCI Express ® , Ethernet, SATA,USB on the backplane CompactPCI ® PlusIO(PICMG 2.30) 100%compatible toCompactPCI ® 2.0 CompactPCI ® Serial(PICMG CPCI-S.0) 100%compatible to 19”mechanics (IEEE 1101) Individual system solutionsfrom inexpensive industrialPCs to redundant systemsor complex computer clustersEmbedded Solutions – RuggedComputer Boards and Systemsfor Harsh, Mobile andMission-critical EnvironmentsMEN Micro, Inc.24 North Main StreetAmbler, PA 19002Tel: 215.542.9575E-mail: sales@menmicro.comwww.men.de/cpci-serialTom Varcie, Senior Account Managertvarcie@opensystemsmedia.comRebecca Barker, Strategic Account Managerrbarker@opensystemsmedia.comEric Henry, Strategic Account Managerehenry@opensystemsmedia.comAnn Jesse, Strategic Account Managerajesse@opensystemsmedia.comChristine Long, Director of Online Developmentclong@opensystemsmedia.comOpenSystems Media Editorial/Production StaffMike Demler, Editorial DirectorDSP-FPGA.commdemler@opensystemsmedia.comJoe Pavlat, Editorial DirectorCompactPCI, AdvancedTCA,& MicroTCA Systemsjpavlat@opensystemsmedia.comJohn McHale, Editorial DirectorMilitary Embedded Systemsjmchale@opensystemsmedia.comWarren Webb, Editorial DirectorEmbedded Computing DesignIndustrial Embedded Systemswwebb@opensystemsmedia.comJennifer Hesse, Managing EditorEmbedded Computing DesignIndustrial Embedded Systemsjhesse@opensystemsmedia.comCorporatePatrick Hopper, PublisherTel: 586-415-6500phopper@opensystemsmedia.comSubscription UpdatesKaren Layman, Business Managerwww.opensystemsmedia.com/subscriptionsTel: 586-415-6500 Fax: 586-415-488230233 Jefferson, St. Clair Shores, MI 48082International SalesElvi Lee, Account Manager – Asiaelvi@aceforum.com.twRegional Sales ManagersBarbara Quinlan, Midwest/Southwestbquinlan@opensystemsmedia.comDenis Seger, Southern Californiadseger@opensystemsmedia.comSydele Starr, Northern Californiasstarr@opensystemsmedia.comRon Taylor, East Coast/Mid Atlanticrtaylor@opensystemsmedia.comSharon Hess, Managing EditorMilitary Embedded SystemsVITA Technologiessharon_hess@opensystemsmedia.comMonique DeVoe, Assistant Managing EditorPC/104 and Small Form FactorsDSP-FPGA.commdevoe@opensystemsmedia.comBrandon Lewis, Associate Editorblewis@opensystemsmedia.comCurt Schwaderer, Technology EditorSteph Sweet, Creative DirectorDavid Diomede, Art DirectorJoann Toth, Senior DesignerKonrad Witte, Senior Web DeveloperMatt Jones, Web Developerwww.opensystemsmedia.comRosemary Kristoff, Presidentrkristoff@opensystemsmedia.comWayne Kristoff, CTO16626 E. Avenue of the Fountains, Ste. 201Fountain Hills, AZ 85268Tel: 480-967-5581 Fax: 480-837-6466Republishrepublish@opensystemsmedia.comPrint ISSN 1098-7622, Online ISSN 1550-0381CompactPCI AdvancedTCA & MicroTCA Systems (USPS 019-288) is published four times a year (Spring, Summer, Fall Winter) by OpenSystems Media,16626 E. Ave of the Fountains, Ste 201, Fountain Hills, AZ 85258CompactPCI AdvancedTCA & MicroTCA 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 $63/year. For first class delivery outside the US and Canada, subscriptions are $90/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 CompactPCI AdvancedTCA & MicroTCA Systems 30233 Jefferson, St. Clair Shores, MI 48082.6 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

NETWORK INTELLIGENCEFigure 2 shows what happens if theexecution times of each code block areequal and E depends on D dependson C depends on B depends on A.You’ll notice – due to the dependencies– no speed-up is achieved. In fact,it’s possible that due to the overheadof communications and data passingbetween cores, the performance actuallygoes down and you end up withmultiple cores that are significantlyunder-utilized!Figure 3 shows what happens if Bdepends on A and D depends on C, andE has no dependencies. Applying thisto a four-core processor can reduce theexecution time to close to the longestexecution time of B/A, D/C, or E. If theexecution time of each of the blocks isequal and takes time “t,” we’ve reducedthe execution time from 5t to 2t on themulticore system.Of course, these illustrations are simplified.Not only might there be dependencies,but there may also be sharedresources to consider. Shared resourceswithin a multicore software environmenttypically need to be made thread-safethrough the use of locks, and passinginformation between threads in a multicoresystem may be more complex if youaren’t using an SMP operating system,which can hide a lot of these complexities.There are some tools on the market thatcan help you with modeling performanceof your software on multicore before youspend the effort reorganizing. Prism,from CriticalBlue, can perform analysis ofsource code, identify where synchronizationpoints and dependencies are, andguide your development to provide someanalysis/benchmarking information tomake sure you meet performance expectationsonce you’ve moved to multicore.Companies like Wind River andMontaVista Software also have a lot ofexperience in SMP operating systems,approaches, virtualization, and developmenttools. Access to those kinds ofresources can be very helpful in acceleratingthe multicore learning curve.Coordination and synchronization ofmulticore applicationsThe next level of issues that arise oncemodeling is complete is one in whichdependencies are identified (and eliminatedif possible) and work begins onperforming communication betweendependent code blocks that may runon different cores. The dependenciescan vary – perhaps it’s a shared resourceamong multiple code blocks like an I/Odevice or a dynamic library call that isnot thread safe. In some cases, the driveror library can be made to run within amulticore environment by doing its ownlocking and synchronization so it’s transparentto the threads of execution. Thisis typically the preferred method when itcomes to sharing resources.Figure 2This example illustrates the amount of time needed for a four-core multicore processorto execute code when each code block is dependent on the preceding code block.Figure 3Fewer or no code block dependencies reduce execution timedramatically over code blocks with multiple dependencies.Data passing is a different animal. Ifyou’re running within an SMP operatingsystem environment, the operatingsystem typically has the same mechanismsavailable to the threads as theywould normally use for data passing –memory queues, pipes, shared memory,and so on. But if you’re running withouta virtualized software layer, care mustbe taken so that no matter which corethe code blocks doing the data passingare running on, a shared memory path isavailable for reading and writing in additionto the synchronization method.Software trendsSoftware support for embedded multicoresystems is also picking up steam. Imentioned CriticalBlue, a company whosesoftware offerings are targeted specificallyfor multicore applications, and traditionalsoftware players like Wind Riverand MontaVista are doing their part aswell, updating their operating systemsfor SMP operation. Traditional softwarecompanies are also developing hypervisors,tighter coordination mechanismsbetween different operating systems forAMP operation, and upgrading analysisand debug tools to be able to better find8 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

and fix bugs that occur during testing.All these updates and improvementspromise to make it easier to developmulticore embedded systems in a moreefficient and cost-effective way.MontaVista presented at anOpenSystems Media webcast last yearentitled “Beyond Virtualization: A NovelSoftware Architecture for Multi-CoreSoCs.” At this webcast, they introducedthe concept of “containers” – lightweightvirtualization that isolates processes andresources without the complexities of fullvirtualization. Containers could be a niceway to implement some applications thatwould benefit from AMP for the isolationand protection of components. Anotherinteresting innovation presented was theconcept of the “Bare Metal Engine.” Thisis something inside MontaVista Linux thatprovides a user mode environment withdirect access to the underlying hardware.There isn’t any kernel mode programmingrequired and you can maximizeperformance on a given core within amulticore processor this way. So there area number of innovations happening in thesoftware world to provide flexibility forthe wide range of applications that cantake advantage of multicore.Hardware trendsBefore finishing up, it’s worth mentioningsome hardware trends for supportingmulticore in a more robustway. Virtualization often plays a bigrole within a multicore environment– as mentioned earlier, an SMP operatingsystem or hypervisor middlewarecomponent can significantly decreasethe complexity of developing multicoresoftware. But adding layers canbe slow, so many multicore processorsare adding instructions to assistwith virtualization tasks. For example,Intel has included the VT-x instructionset, and the Freescale e500mc andARM Cortex-A15 also include instructionsassisting with virtualization thatSMP operating systems and hypervisormiddleware developers can take advantageof. Within the processor, multiplelevels of caching and/or independentcaches for each core can be importantfor faster instruction execution.Smarter I/O and device drivers are alsoa significant trend supporting multicore.As mentioned previously, offloadingnetwork protocol work, providing multithread/multicorequeuing, and deliverywithin an I/O device also helps with multicoresoftware development. Some I/Odevices also provide special interruptconfigurations to allow for special usecases in a multicore environment.The multicore trendCan your embedded system benefit frommulticore? Hardware and software supportfor multicore processors is reachingcritical mass. If you’re looking to consolidatecomponents and increase yourperformance/power ratio, now is thetime to be investigating how a multicoresolution might work for you. Whileit’s true that multicore development canbe more complex than traditional singlecoreCPI development, tools and technologyhave advanced to the point thatmulticore adoption is accelerating and anincreasing knowledge base is available tohelp. In light of the fact that embeddedsystems competitors are likely alreadylooking into multicore, perhaps thebetter question might be “Can you affordnot to explore a multicore solution?”

By Mike Demlermdemler@opensystemsmedia.comBase stations-on-a-chip deliver the lowercost per bit promise of 4G LTE networksOne of the advantage often attributed to4G LTE over 3G networks is the promiseof lower transmission cost per bit for networkoperators. Potential savings start atthe Radio Access Network (RAN), wherehigher spectral efficiency (measured inbits per second per Hz) is achieved withLTE’s Orthogonal Frequency DivisionMultiple Access (OFDMA) downlinkand Single-Carrier Frequency DivisionMultiple Access (SC-FDMA) uplink modulationschemes, enabling operators topush more data through available bandwidth.On the core network side, the flat,all-Internet IP architecture defined bythe 3rd Generation Partnership Project’s(3GPP) Release 8 standard –the EvolvedPacket Core (EPC) – means fewer layersof equipment between base station andthe user, and an eventual convergenceof voice and data systems with VoLTE.Lower cost per bit sounds good theoretically,but to achieve it many morenetwork processing functions must beput into the base station. 4G standardsmakers dubbed this improved base stationthe evolved NodeB (eNodeB), asimple term that doesn’t quite convey thesystem’s complexity. Designers must integratemultiple heterogeneous processorcores, DSPs, and specialized acceleratorsfor the baseband Layer 1 and Layer 2operations, along with general-purposeCPU cores for Layer 3 control plane functions.These Systems-on-Chip (SoCs) alsomust support the scalability that serviceproviders will need, as they build out LTEnetwork coverage with a mix of macrocellsand picocells. However, throughthe combination of Moore’s Law anddesigner ingenuity, semiconductor vendorsare delivering on that lower costper bit promise with “base stations-ona-chip,”providing all of the functionalityrequired for an eNodeB in a singledevice. Here is a short review of some ofthe competitive offerings.In their OCTEON Fusion small cell SoCfamily, Cavium offers a range of configurationsfrom two 64-bit MIPS processorcores and four (Tensilica-based) DSPcores for 32 users, up to six MIPS coresand eight DSP cores able to support300 users. Cavium touts compatibilitywith their OCTEON macrocell processors,which require separate physicallayer (PHY) DSPs, and the full stack ofOCTEON L2-L7 software.DesignArt Networks uses 12 TensilicaDataplane Processor Units (DPUs) intheir 22-core SoCs in combination withsix of their proprietary DSP cores anda quad-core ARM controller. DesignArtclaims that their DAN 3000 does notrequire any change in architecture forheterogeneous networks, and by integratingdifferent I/Os they can addressmacro, micro, or picocell applications.Freescale offers the PSC9132/31/30 forfemto/picocells, and the new B4860for macrocells. The B4860 integratesquad clusters of the 64-bit e6500Power Architecture cores with 128-bitAltiVec vector processors and threesets of dual StarCore SC3900 DSPcores, with a Maple-B3 core to offloadthe DSPs for Layer 1 acceleration. TheSC3900 received the highest fixed-pointBDTIsimMark2000 benchmark scoreever recorded by analysis firm BerkeleyDesign Technology, Inc. (BDTI). Freescalesays their macro SoC can replace five discretecomponents: three DSPs, a SerialRapidIO (SRIO) switch, and a separatenetwork processor for Layer 2 to Layer 3transport and control functions.Mindspeed’s Transcede 4000 combines10 custom application processorcores with CEVA DSP cores in thesignal processor cluster, along with sixARM Cortex-A9 cores in a dual/quadsystem cluster. Designers can use theTranscede on-chip network to scaleup to networks of multiple TranscedeSoCs to construct larger base stationsby assigning one device’s dual core asthe master dispatcher to manage theother networked processors.Texas Instruments has the semiconductorindustry’s first quad-core implementationof ARM’s latest Cortex-A15 processorwith their TCI6636 base station-on-achip.The TCI6636 also contains eight ofTI’s C66x DSP cores, with acceleratorssuch as network and security coprocessorsfor infrastructure applications. TI istargeting the new device at small cells ofup to 256 users, joining the TCI6612 andTCI6614 for pico/femtocell applications.TI says that three TCI6636 SoCs can begrouped together to form a macrocellbase station, offering a cumulative savingsof 75 W and reducing cost by $625by eliminating the network processor andother conventional components.With so many options now availablefor base stations-on-a-chip, designersof eNodeB systems will need to usedue diligence when comparing siliconcapabilities. Each vendor has architectedtheir SoC in different ways, withdifferent Semiconductor IntellectualProperty (SIP) cores for the key functionblocks. Software support for theLTE protocol stack is also a critical elementto consider, along with the choiceof processing hardware, as the EPCarchitecture continues to promote lowercosts per bit.10 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

Hardware Platform ManagementCOTS management building blocks forAdvancedTCA: Proven over the first decadeBy Mark OvergaardTen years ago, in 2002, PICMG was working hard to complete the AdvancedTCAspecification that was formally adopted on the last day of the year. The hardwareplatform management section accounted for 30 percent of the 430 specificationpages. Late in the year, prototype ATCA shelves and boards were tested at PICMG’sfirst interoperability workshop, and the first prototypes of COTS management buildingblocks were delivered to early customers. It was already clear, however, as productdevelopment efforts ramped up, that the hardware platform management subsystem ofATCA represented a significant implementation challenge.The first COTS management buildingblocks for ATCA were announced threeweeks after specification adoption.Soon thereafter, in 2003, those buildingblocks were delivered and describedin CompactPCI Systems articles,“Management Building Blocks SpeedAdvancedTCA Product Development”in the March issue, and “Off-the-ShelfManagement Solutions for AdvancedTCABoards” in the May/June issue. Also thatyear, the PICMG interoperability workshopsstarted including explicit testing ofthe ATCA management layer.How has ATCA and its managementlayer evolved in the last decade?Fast forward to 2012, and the marketfor just commercial ATCA CPU boardsand AdvancedMC (AMC) CPU modulesis projected by VDC Research to exceed$550 million (the overall ATCA marketincludes major segments not coveredby this forecast). Another study, doneby Heavy Reading in 2011, forecasts a31 percent annual growth rate for theoverall xTCA market (which is dominatedby ATCA and AMC modules used inATCA systems), culminating in a marketworth $4.3 billion by 2015. Every ATCAorAMC-compliant board, module, andshelf must have a corresponding specification-definedmanagement controller.Tens of thousands of ATCA shelves, eachpotentially with a dozen or even dozensof management controllers, have nowbeen delivered with COTS managementtechnology. Major ATCA/AMC customers,such as Tier 1 TEMs, are identifyingmanagement-level interoperabilityof ATCA and AMC products as veryimportant to their success and confirmingthe benefits of using COTS managementcontrollers.Meanwhile, the specification contentrelevant to the xTCA management layerhas grown substantially, and includes:435 pages of management sectionsfor the base specifications for ATCA,AMC, and MicroTCA66 pages for PICMG HPM.1,which defines a firmware upgradearchitecture for xTCA managementcontrollers130 pages or so for the PICMGHPM.2 and HPM.3 specifications,now nearing completion withinPICMG (These specifications addressLAN-attached xTCA managementcontrollers, which have a LANconnection to supplement themandatory Intelligent PlatformManagement Bus (IPMB) link to theirsupervising layers)568 combined pages for the ServiceAvailability Forum (SAF) HardwarePlatform Interface (HPI) specificationand the corresponding mappingspecification from HPI to the xTCAmanagement layerPICMG has now held more than 30interoperability workshops and there arenow commercially offered formal compliancetest suites for xTCA managementand HPI offered by Polaris Networks.Considering the mounting body of contentpertinent to the management layer,Nokia Siemens Networks and otherxTCA users see particular benefits ofCOTS building blocks developed by aCOTS management controller specialistwho is immersed in the multitude ofrequirements embodied in these widerangingspecifications. In addition toparticipating in PICMG interoperabilityevents and applying commercial testsuites, these specialists need to demonstratea deep commitment to specificationcompliance and interoperability inmanagement functionality.What functions does an ATCA shelflevelmanagement controller provide?Figure 1 shows the context and majorsubsystems of a typical ATCA ShelfManager, including the following:Shelf Manager physical instancesShelf Manager interface optionsShelf Manager subsystemsCompactPCI, AdvancedTCA & MicroTCA Systems | Summer 2012 | 11

Hardware Platform ManagementThe logical Shelf Manager includes twophysical instances, active and standby.Via a Software Redundancy Interface(SRI) and Hardware RedundancyInterface (HRI), the standby instancekeeps tabs on what is happening in theshelf so it can take over quickly if necessary.Both physical Shelf Managerinstances are connected to both ATCAhub boards in the shelf so that a higherlevel system manager has continualaccess to the logical Shelf Manager incase of a malfunctioning hub board,Shelf Manager instance, or both.Several interface options are provided bythe logical Shelf Manager for use by thesystem manager, though the only specification-mandatedinterface is an IPMIorientedRemote Management ControlProtocol (RMCP). Others, including aCommand Line Interface (CLI), SimpleNetwork Management Protocol (SNMP),or a web interface (HTTP) are typicallyavailable as well. One popular interfaceis a set of Application ProgrammingInterfaces (APIs) called the HardwarePlatform Interface (HPI), which is maintainedas an open standard by the SAF.The logical Shelf Manager has a varietyof subsystems, responsible for cooling,fabric connectivity, power, and othermanagement areas. There is typicallyalso a Shelf Adaption Layer to adaptthe Shelf Manager for operation in aparticular shelf, with its complementof auxiliary resources, such as powerentry modules, fan trays, and the supportedpopulation of boards, each withits local management controller.What is HPI’s role in themanagement of ATCA systems?HPI is widely used in ATCA systems asthe bottom layer in system managerapplications to isolate those applicationsfrom the implementation detailsof the hardware platforms they supervise.In addition to the implementation-independentAPIs for HPI, thereis an open source implementation ofthese APIs called OpenHPI, which iswidely used as well.CROSS-CONNECTEDHUBSLOGICAL SHELF MANAGERRMCPShelfDefinitionPowerEntryHPISystem ManagerCLIviasshSRIActiveStandbyHRIPHYSICAL SHELF MANAGERSKEY MANAGEMENT SUBSYSTEMSPower Cooling Fabrics FRUsShelf Adaptation LayerSensorsFansFigure 1SNMPIPMB-0HTTPEventsIPMCCarrierIPMCDual redundant shelf manager instancesoffer system manager interfaces andimplement key functional blocks tomanage shelf operation.MODULARVIDEO GRAPHIC SOLUTIONSMil-810, IPC class-3, RIAC, Extended TemperatureContactfor: Video inputs and outputs: NTSC/PAL, STANAG, RS-343,RGB, TMDS, LVDS, DVI, HDMI, DP, CameraLink, andSMPTE: 259M, 344M, 292M, 372M, 424M H.264, VC-1, MPEG-2, MPEG-4 part 2 encoders and decoders AES encryption and decryption GPU - AMD X1400, AMD E4690, AMD E6760 AMD, XILINX and ALTERA Video Driver developmentTeraFLOP GPGPU12 Video OutputsWOLF Industrial Systems Inc.1.800.931.4114 www.wolf.caCelebrating 20 years of Innovation!VPXCompactPCI-S.0COM ExpressXMCPMCMXM3U VPX Carrier with Dual MXC Modules OpenGL, DirectX, VxWorks, Integrity, Windows, Linux Gigabit Ethernet video, USB-3.0 video, PCIe video GPGPU - Parallel processing OpenCL1.1 and CUDA FPGA HDL custom design services Custom Board design and manufacture Custom COM Express ® baseboardsFor more detailed descriptions of WOLF’s modules and their cutting-edge advances in video graphics functionality, go to www.wolf.ca/modularMXCATCAAMC12 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

Hardware Platform ManagementAdaptableAdvancedTCA ShelfManager FirmwareBy Michael ThompsonAn AdvancedTCA (ATCA) shelf (or “chassis”) manufacturer provides perspective onaddressing the mandate that all ATCA-compliant shelves include a sophisticatedShelf Manager, as well as managing adaptations to Shelf Manager functionality as theproliferation of ATCA generates an increasing range of customer-specific variations.An AdvancedTCA (ATCA) Shelf Manager controls the behaviorof boards and other shelf Field Replaceable Units (FRUs), monitorstheir health, and manages power and cooling in order toensure proper operation of the system. If something is notbehaving as expected, the Shelf Manager can take correctiveaction and send alert messages containing sensor readingsto a higher level System Manager. Since manufacturingdata is stored within each element in the shelf, including theshelf itself, the Shelf Manager can also provide detailed inventoryinformation. This data, togetherwith other configuration informationstored within an ATCA FRU, is collectivelycalled “FRU information.”The responsibilities of a ShelfManager are challenging because thecomplement of boards and FRUs thatwill be found in the shelf is not knownwhen the Shelf Manager powerson. Together, the ATCA and IPMIspecifications provide a standardizedmethod for the Shelf Managerto determine what boards and FRUsare installed in the shelf, and whatresources each needs. Much of thisdata is contained on the FRUs in theshelf, and the Shelf Manager determineswhat resources and capabilitiesare available by accessing theshelf-level FRU information. This createsa very dynamic environment atshelf power-on. Figure 1 shows themanagement aspects of an exampleATCA shelf, including AdvancedMC(AMC) sites.ShelfManager(Active)ShMCIPMCATCA BoardSystem ManagerShelfManager(Backup)ShMCMaking the shelf manageableWhen deciding to manufacture its first ATCA shelf, Pentair/Schroff determined that developing Shelf Manager firmware wasbeyond its capabilities. After surveying possible partners for aCOTS Shelf Manager, a Shelf Manager design was constructedbased on a Pigeon Point Systems (PPS) hardware referencedesign. PPS delivered Shelf Manager firmware that includeda shelf adaptation layer specifically for a Pentair/Schroff ShelfManager and shelf hardware design.Shelf FRUInfo [1..2]ATCA/AMC Specification ElementsShelf ManagerShelf Management Controller (ShMC)IPM Controllers—Several VariantsAMC ModuleOther Field Replaceable Unit (FRU)AdvancedTCA Board and Optional RearTransition Module (RTM)Power EntryModule[1...N]Implementation-Defined ConnectionsOptional RTMCarrierIPMCAMCAMCMMCMMCATCA BoardIPMB-LOptional RTMFan Tray[1...N]IPMCFigure 1CarrierIPMCATCA BoardPotential Pigeon Point Product Sites1. Shelf ManagersShelf-SpecificShMM CarrierRunning Pigeon PointShelf ManagerShMM-500RBMR ControllerReference Design2. IPM Controllers—Variants for Distinct Typesof Boards and FRUsRunning Pigeon PointBMR FirmwareOptionally Implemented inSmartFusion or FusionMixed-Signal FPGAsCompactPCI, AdvancedTCA & MicroTCA Systems | Summer 2012 | 15IPMB-LMMCOptionalIntelligent RTM2x Redundant, Bused or Radial, IPMB-0IPMCATCA Board2x Redundant Radial Internet-Protocol-Capable TransportAll of the the FRUs have FRU information stored on them,including the shelf itself, as illustrated in this example.Optional RTM

Hardware Platform ManagementWhen a second ATCA shelf was created, PPS modified theshelf adaptation layer to match the new shelf. As time wenton, numerous Shelf Managers and shelf designs were created,and the hardware and Shelf Manager firmware were subsequentlymodified to customer-specific requirements. For eachPICMG InteroperabilityWorkshopsOne of the strengths of AdvancedTCA is its rich ecosystem ofshelves and boards, and the extent to which independentlyimplemented shelves and boards work together. One wayin which the PCI Industrial Computer Manufacturers Group(PICMG) helped to achieve this strength is by organizing xTCAInteroperability Workshops (TCA-IWs) to create a forum forshelf and board manufacturers to mutually test their products.The TCA-IWs have proven to be an excellent opportunity totest the behavior of shelves and boards in a very mixed environment.They have also allowed the consortium to ensurethat our COTS adaptations work with other manufacturers’COTS adaptations or internal implementations of the hardwareplatform management layer. Experience has shown thatwidely adopted/adapted COTS building blocks benefit fromthe broad testing received in the workshop context.VEROTECINTEGRATEDPACKAGING Continuing 50 years of excellence in bespoke thermally managed,ag powered and wired systems for cPCI, VME, VME64x, VPXand other major bus structuresELECTRONICS PACKAGINGnew Shelf Manager or shelf design, PPS had to modify theshelf adaptation layer in the Shelf Manager firmware, thenPentair/Schroff would run extensive regression testing toensure that none of the firmware behavior for earlier hardwaredesigns was broken. Eventually debugging and validatingeach new firmware modification developed into a painful andtime-consuming process, and as the shelf adaptation layermodifications in the Shelf Manager firmware grew in complexity,this approach became unmanageable.PPS took on this firmware development challenge by creatingtheir Hardware Platform Description Language (HPDL) for theShelf Manager and shelf hardware. The HPDL describes the I2Cdevices on the Shelf Manager board and on non-intelligent shelflevelFRUs. If an I2C device supports GPIO, the HPDL describesthe “signals” that are connected to the GPIO device. The HPDLalso describes the relationship between the I2C devices, signals,and ATCA Sensor Data Records (SDRs).To make the distinction between Shelf Manager FRU informationand shelf-level FRU information more clear, Figure 2 showsan example Shelf Manager board, including the COTS ShelfManager module that is mounted on it. This board is designedto fit into a specialized slot in a shelf. There are usually two suchslots in the shelf to support Shelf Manager redundancy. TheShelf Manager FRU information, including the HPDL describingthe Shelf Manager board, is on the board itself. The shelf-levelFRU information is usually stored in dual-redundant SerialEEPROMs (SEEPROMs) implemented on the shelf backplane.Translating HPDL and its benefitsWhen the processor on the Shelf Manager boots, it first readsits own FRU information from a local I2C SEEPROM. This FRUinformation contains HPDL records that describe the I2Cdevices on the Shelf Manager, as well as records describing theoff-board SEEPROMs that hold the shelf-level FRU information.The Shelf Manager then reads the shelf-level FRU informationand the shelf HPDL records. At this point the Shelf Managerhas all of the information it needs to completely configure allof the non-intelligent FRUs in the shelf. If the Shelf Manager issubsequently installed in a different shelf, it will find a correspondingset of HPDL records in the shelf-level FRU informationSEEPROMs and automatically adjust its behavior to match therequirements of that new shelf.Figure 2An example Shelf Managerboard, including the COTS Shelf Manager module.16 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

The HPDL example in Figure 3 describes an ATCAfan tray containing the LM75 temperature sensor,AT24LC256 SEEPROM, and PCA9555 GPIO devicethat is a non-intelligent FRU on the Shelf Manager(an FRU that doesn’t have an IPMC). The ADM1026fan controller IC that detects the fan tray presenceis actually on the Shelf Manager. One of the moreinteresting features of HPDL is “Periodic Action.” Inthis example, the state of the fan tachometer sensorand the -48 V presence sensor is evaluated once persecond, which controls the state of the red and greenstatus LEDs.It is also possible to build shelf-level FRUs that incorporateIPMCs, rather than being non-intelligent likethe fan tray described in the HPDL above. Initially,Pentair/Schroff chose to implement non-intelligentFRUs to reduce development time and to eliminatesix instances of firmware and microprocessors in theshelf. Newer shelf designs have IPMCs on the fantray FRUs because of their increased design complexity;this is the approach represented in Figure 1.In either case, by using HPDL stored in the ShelfManager and shelf-level FRU information, ShelfManager firmware can be quickly adapted to anew Shelf Manager or shelf design, and even thebehavior of the Shelf Manager itself can be modifiedto customer-specific requirements. Figure 3This HPDL “Periodic Action” code commands the Shelf Manager toevaluate the status of an ATCA fan tray once per second.CompactPCI, AdvancedTCA & MicroTCA Systems | Summer 2012 | 17

Hardware Platform ManagementRegressing the cost of regression testingTypically, a widely used Shelf Manager implementation includesextensive configuration file options that let the user tailor itsbehavior to their needs. Standard Shelf Managers are shippedwith a generic set of configuration settings in the firmwareimage that works for most users. Since the HPDL configurationis stored in the Shelf Manager and shelf-level FRU information,changes are specific to a particular Shelf Manager or shelfpart number; because the Shelf Manager firmware itself is notmodified, this method eliminates the need for time-consumingregression testing whenever a new Shelf Manager or shelfvariant is developed or modified. Design validation testingis still required, but only for the new Shelf Manager or shelf.This approach also provides the added benefit of being ableto order a special part number Shelf Manager that has the customizedfirmware installed. No Shelf Manager configuration isrequired by the customer, so product configuration control issimple and opportunities for errors are reduced.As an added adaptation, Shelf Manager vendors can also providecustomer-specific firmware images that include modificationsto the configuration files in the Shelf Manager, as well aschanges to the HPDL and FRU information in the Shelf Managerand shelf. Since these changes are only in the configuration andHPDL files and not the binary firmware executable files, regressiontesting is not necessary in these cases either. Eliminatingthe need for that regression testing reduces the cost of theShelf Manager and shelf, making it more competitive in themarketplace.Implementing IPMB in the shelfThe ATCA specification mandates a dual redundant IntelligentPlatform Management Bus (IPMB-0) that is used to connectthe Shelf Manager to intelligent FRUs in the chassis. The IPMBcan be implemented with topologies from fully radial to bused,all of which maintain the dual redundancy of IPMB-0, whichShelf ManagerIPMB-0Hub AIPMB-0Hub BShelf ManagerIPMB-0Hub AIPMB-0Hub BIPMC IPMC IPMCFigure 4A description of the radial IPMB-0 connections from ShelfManagers to IPMCs, with separate IPMB-A links (solid) andIPMB-B links (dashed).aggregates the traffic on IPMB-A and IPMB-B. An IPMC in anFRU works with any IPMB-0 topologies.The bused topology is simple to implement in the ATCA backplaneand Shelf Manager because a COTS Shelf Managermodule can implement both the IPMB-A and IPMB-B parts of theIPMB-0, so the Shelf Manager board just connects these signalsto the IPMB-A and IPMB-B buses in the backplane. Some systemarchitects prefer the simplicity of a bused IPMB-0; others areconcerned that a single faulty IPMC could disable the entire bus.With radial topology, however, there are individual IPMB connectionsfrom the Shelf Manager to each of the IPMCs (Figure 4) andfailure on one of those connections does not affect the others.The two most common implementations of radial IPMB-0 hubsare physical stars and logical stars. The physical star is usuallyimplemented by buffering bused IPMBs from the Shelf Managermodule through a circuit with a controllable I2C driver for eachIPMB port. In this approach, there is still a single logical IPMB-0,but with separately controllable physical segments to eachintelligent FRU position in the shelf. The logical star is typicallyimplemented with one or more FPGAs containing a discreteI2C controller for each IPMB link. In this arrangement, eachlink is a separate logical IPMB, which can yield performanceor other benefits. With either implementation the radial IPMBlinks are individually controllable. If the Shelf Manager detectsan IPMB failure with an FRU, it deactivates the offending linkon the corresponding IPMB hub and the remaining links continueworking. Since the link failure may be transient, the ShelfManager can periodically enable and retry the deactivated link.Shelf Manager firmware needs to adapt to any physical implementationof IPMB-0 in the system. If the ATCA Shelf Managerand shelf have a radial IPMB-0 topology, the shelf FRU informationcontains a special record. If it finds this record, the ShelfManager configures itself for a radial IPMB-0 topology; otherwiseit defaults to a bused IPMB topology. Hardware implementationof the radial IPMB-0 hub is usually specific to a manufacturer, andthe Shelf Manager firmware could include an adaptation modulefor radial hardware implementation.Managing a growing ecosystemThe complexity of ATCA systems and the applications runningon them has increased significantly in the past decade, andmonitoring the health of the system environment has becomevery important. As ATCA enters its second decade, the ShelfManager function that is required in compliant ATCA shelveshas proven its value in tens of thousands of deployed shelves.The dramatic growth of ATCA box shipments requires carefulmanagement of the numerous customer-mandated shelf variantsthat are a crucial aspect of this growth.Mike Thompson is the Principal Engineer at Pentair TechnicalProducts (Schroff).Pentair Technical Products (Schroff)michael.thompson@pentair.comwww.pentairtechnicalproducts.com18 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

Hardware Platform ManagementHow one TEM leverages ATCAHardware Platform ManagementBy Jari RuohonenNokia Siemens Networks (NSN) has made a strategic choice to take maximumadvantage of the open architecture benefits of AdvancedTCA (ATCA) for its productofferings. ATCA’s hardware platform management architecture is a critical part ofthose benefits and crucial to NSN and its customers.Numerous benefits result from using ATCA for NSN’s OpenCore System (the foundation of NSN’s ATCA-based products).Overall, the footprint of the hardware can be up to 80 percentsmaller and energy consumption up to 40 percent lesscompared to previous products. At one NSN customer, forexample, two racks of existing equipment were replaced by asingle ATCA shelf implementing a Mobile Softswitch Solution(MSS). Figure 1 shows how the functionality of a full core networksite can be implemented in two ATCA racks.One contributor to both reductions is that the number of pluginboards can be reduced by up to 80 percent because of thegood density that ATCA enables. In addition, the number ofdistinct board types is reduced because the boards are applicableto many different purposes, which translates to biggervolumes and reduced cost.There are two main board types used in all NSN ATCA applications:the CPU blade (x86 server blade), and the HUB blade(Ethernet switching). In addition, there are specialized bladesfor specific gateway types, including:Multicore Packet Processing (MPP) bladeDigital Signal Processing (DSP) bladeAMC Carrier blade (carrier for networkinterface AMCs)The MPP blades, for example, can handleboth the user plane implementation up tolevel 4 and the control plane implementationflexibly within the same COTS blade,for which there are multiple competingvendors around the world. Some non-ATCA solutions, in contrast (such as thosebased primarily on ASIC-intensive routertechnology) have specialized proprietaryhardware to address the same functionalityand cannot evolve as quickly or takeadvantage of the worldwide, competitiveCOTS blade market.ATCA’s Hardware Platform Management (HPM) inNSN strategyThe NSN ATCA strategy has two key aspects dependent on HPM:Aggressive incorporation of successive generations ofCOTS ATCA blades and AMC modules, with each multivendorgeneration representing the best-in-class offeringof the ATCA ecosystem for each functional area. Thisgives NSN customers a unique possibility to amortizetheir ATCA investment over a long period by introducinglatest generation boards with rhythms appropriate to thechanges and growth of their networks.Software platforms isolate network application softwarefrom hardware. From an application point of view, thisseparation enables developers to focus on the applicationswithout being distracted by hardware bring ups orother High Availability (HA) and carrier-grade featuresoffered by foundation software platforms. In fact, thesesoftware platforms even span the differences betweenNSN’s pre-ATCA equipment and the current ATCA-basedequipment. This allows optimal software reusability fromexisting mature applications, as hardware and higher levelapplication layers are not dependent on each other.Common COTS HW for all core elementsWBenefitsATFigure 1An example of a core network site in two ATCA racks.CompactPCI, AdvancedTCA & MicroTCA Systems | Summer 2012 | 19

Hardware Platform ManagementThe time-to-market for COTS ATCA blades and AMC modulescan be very short; this enables NSN to provide quick access forits customers to the latest generation of silicon. Quick introductionof new silicon also maximizes the effective board andmodule lifecycle. NSN’s customers can at the same time benefitfrom state-of-the-art technology, and cost-effective investments,as these boards and modules are not already outdatedwhen delivered to end customers.In addition, standard HPM helps to ensure upgradeability overATCA board generations. Operators don’t need to replace theexisting network elements when requiring more capacity overthe years. Only updates of payload boards and modules arerequired. Consider, for example, the third and fourth generationsof NSN’s ATCA architecture, which are mainly distinguishedby the fact that the fourth generation supports 40 G capacityon its in-shelf networks. In the third generation, NSN includeda 40 G-capable backplane. Therefore, upgrades to the fourthgeneration only require replacing the 40 G hub boards and anyother boards that need to communicate at 40 G. 10 G-focusedboards do not need to be replaced because the 40 G hub boardsare backward-compatible with 10 G.Implementations of the ATCA HPM layer have continued tomature over the four generations of NSN’s ATCA products. Atthe blade and module level, our experience confirms a significantadvantage in basing the mandatory local controllers on COTSimplementations that benefit from widespread implementationand mature interoperability characteristics. At the shelf levelNSN has been well served through all four generations by thesame widely used and stable COTS Shelf Manager.The Service Availability Forum’s (SAF’s) Hardware PlatformInterface (HPI) plays a key role in achieving a well-managedlayer between the hardware and software platforms. HPI hidesthe complexity of ATCA’s internal IPMI structures and makes itpossible to define an Application Programming Interface (API)between the hardware and software platforms. In systems withhardware building blocks from various sources, HPI’s role isessential. Without HPI, ATCA system integration would not beas successful as it is now.Specifically, as Figure 2 shows, the hardware independenceof HPI allows the software platform, which represents massiveTEM and/or TEM customer investments, to be used withmultiple generations of hardware, including both ATCA andpre-ATCA hardware. For the pre-ATCA hardware, an opensource implementation of HPI called OpenHPI can be used,leveraging its plug-in architecture to cover multiple hardwareplatform variants. For our ATCA hardware, the Shelf Managerhas a built-in IntegralHPI, which supports the same client interfaceas OpenHPI, extending HPI’s portability across multipleATCA generations as well.The achievement of software independence across the previousnon-ATCA and current ATCA equipment benefits from thefact that the hardware management layer for the earlier NSNequipment is based, like ATCA’s, on the Intelligent PlatformManagement Interface (IPMI) in a CompactPCI context. Infact, NSN’s deep experience with HPM-enabled CompactPCIequipment was a contributing factor when the HPM strategyfor ATCA was chosen a decade ago.HPI-Based Software PlatformClient LibraryServerPlug-in 1 Plug-in 2ShelfManagerwithIntegralHPIShelfManagerwithIntegralHPIPre-ATCAH/WPlatform APre-ATCAH/WPlatform B3rd GenATCA H/WPlatform4th GenATCA H/WPlatformFigure 2HPI enables a software platform that is largelyindependent of the hardware platform.20 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

Customer reception of NSN’s ATCA productsNSN’s currently released ATCA portfolio covers a wide varietyof applications, ranging from voice core to high-end LTEpacket core products. By the end of 2012, NSN expects tohave more than 10 different applications utilizing the samehardware base. With ATCA, NSN and our customers gain thescalability and versatility needed for building up multipurposehardware installations. NSN customers have been especiallypleased with the performance, scalability, and payback time ofATCA hardware. NSN’s ATCA-based Open Core system is in usetoday around the world. Installations supporting hundreds ofthousands of subscribers are seeing strong growth in the numberof live networks and continuing subscribers.Improvements in ATCA HPM:A TEM’s takeThe HPM facilities of ATCA areworking well for NSN’s ATCAbasedproducts. NSN is countingon further improvements in thislayer as it continues to ramp upthe sophistication and reach ofits ATCA offerings. The HPM.2specification (for LAN-attachedIPM Controllers (IPMCs)) thatis nearing completion in thePICMG HPM.x subcommitteeshould enable the use of backplaneEthernet connections toIPMCs as a supplement to thecurrent mandatory I2C-basedbackplane connections. Suchconnections could drastically(by as much as a factor of 10or more) speed up firmwareupgrades, for example.Comprehensive use of Ethernet-based paths for this retrievalcould dramatically reduce startup times.HPM.2 implementation is on the path to the post-ATCA openplatforms sketched by the SCOPE Alliance, which includes allTier1 TEMs. SCOPE recommends the future platform architecture(targeted to span 2015-2025) reuse ATCA HPM with extensions,replacing the main IPMB with at least 100 Mbps Ethernet.Jari Ruohonen is Head of Core Platform HW ProductManagement and ATCA Product Line Manager at NSN.Nokia Siemens Networks (NSN)jari.ruohonen@nsn.com | www.nokiasiemensnetworks.comPIGEON POINT SYSTEMSW O R L D - C L A S S M A N A G E M E N T C O M P O N E N T SCelebrating 10 Years of DeliveringxTCA Management SolutionsOver the decade, these solutions have been intensively tested in PICMG ®plugfests and by leading TEMs and their suppliers, then incorporated in tensof thousands of shelves, plus hundreds of thousands of boards and modules,worldwide. They are supported by xTCA management experts who helpedlead the development of the corresponding PICMG specifications.The 1 Gbps Ethernet BaseInterface already reaches everyATCA blade, and AMC carrierblades typically provide similarfabric to their AMCs. This is ahuge step up from 100 KbpsIPM Buses (IPMBs), especiallyfor large firmware upgradeimages, even if the IPMC links tonetworks that run no faster than100 Mbps. With comprehensiveimplementation of the HPM.2specification in next-generationATCA platforms, faster speedscould benefit not only firmwareupgrades, but other areas ofATCA performance as well. Forinstance, complicated ATCAconfigurations take substantialtime to power up due to voluminousconfiguration informationthat must be retrieved fromthe shelf blades and modules.ATCA IPM Controller CoreBased on SmartFusion FPGA Delivered as schematic with firmware andFPGA design for integration into customerboard or module Runs firmware on ARM ® Cortex ® -M3 builtinto FPGA; FPGA logic implements someIPMC functions, plus customer functions Easily customized at schematic, firmwareand/or FPGA design levels Corresponding solutions for all xTCAboard/module controller types info@pigeonpoint.comwww.pigeonpoint.comNew ShMM-700R-Based ATCA ®Shelf Manager 30% less expensive, 20% smaller,fully compatible with market-leadingShMM-500R Installed on customer-designedshelf-specific carrier boardCompactPCI, AdvancedTCA & MicroTCA Systems | Summer 2012 | 21

InterviewThomas Kastner, Chief Architect x86 Software,Advantech Networks & Communications GroupThomas Kastner runs Advantech’splatform management teamresponsible for system managementfirmware and software based onPICMG standards and IPMI (IntelligentPlatform Management Interface),coordinating multiple developmentteams worldwide.What is Advantech’s history inplatform management?We gained our IPMI experience withTEMs in the early days of CompactPCIwhile adapting IPMI firmware to severalof our key customer’s platform managementspecifications. We went on to successfullylaunch our first ATCA bladesemploying third-party platform managementproducts. This helped us achievetime-to-market goals with new technologiesand meet initial customer deploymentneeds with an industry-testedsolution. However, as customer demandincreased and we expanded our ATCAand AMC lines, we felt we could serviceand maintain customers better byconsolidating code bases across architecturesthrough a common platformapproach to IPMI. This led to a groundupdesign using our own code.What did you want to achieve bydeveloping your own code?Our vision was a flexible, modular solutionusing a hardened RTOS that metthese goals:Easy-to-customize for fasterdevelopment of customer-specific orvalue-added featuresEasy-to-maintain for improvedlifecycle management and fasterbug fixes in the fieldCommon value add feature setavailable to customers using ATCAand AMCsHigher reliability through broadercross-platform use and testing,leading to faster time-to-maturityIPMI adaptation is a cornerstone of ourCustomized COTS (C2OTS) program.Most major customers require us todevelop special features beyond thestandards, so by meeting the abovegoals it’s easier to maintain multiple versionsand offer branding options and differentiationto customers.Which platforms run your IPMI code?We selected a single platform based onCortex-M. This allows us to source multiplevendors, offering a wider choice ofdevices for our product range. SeveralSKUs of Cortex-M3 are supported, providingenhanced scalability to balancecost and features while leaving sufficientheadroom for future requirements or customization.Implementation of a slim andreliable RTOS provided us with all theessentials needed, such as timers, semaphores,tasks, and so on, and liberated usfrom previous code dependencies.If IPMI is a standard, why iscustomization required and how doyou manage it?PICMG 3.0, AMC.0, and MTCA.0 basetheir hardware management on IPMI1.5 with PICMG-specific extensions.However, OEMs often require specialfeatures for legacy compatibility or managementservice enhancements for theircustomers.IPMI message handling and otherkey elements of our IPMI solution aredesigned to maximize flexibility. Thisallows us to add more features withoutrewriting a lot of code and makes customfeature implementation much easier.As we share code across different productsand projects, it rapidly matures.If we implement a new feature on anATCA blade, it is a fraction of the effortto port it to an AMC, meaning more featuresin less time across a wider rangeof products. Rolling out new features,updates, and bug fixes has become simpleras testing efforts have significantlydecreased. Customers enjoy fasterupdate cycles and benefit from resolutionsin other projects.Where does Advantech bring valueaddto customers?We support HPM.1-compliant updatesfor programmable components suchas BIOS, firmware, FPGAs, and so on.Most firmware images are fully redundant,for example for dual BIOS chips,dual firmware, and FPGA images;IPMI handles automatic rollback incase of update failures or integrityissues. For advanced remote configuration,Advantech-specific featurescan remotely modify BIOS settingsor switch between sets of customerdefinedsettings. Serial-over-LANalso allows remote IPMI-based accessto the system console. For progressmonitoring needs we support automaticBIOS failover in case of startupproblems with BIOS POST sensors loggingthe POST code where the boardhangs. This information can be used todebug boot-up issues. We have alsoimplemented features to improve crashanalysis, for example, by dumping thelast few KBs of system console outputover IPMI for post-mortem debugging,accelerating debugging significantly.We also added Advantech’s time syncfeature to allow options for system timesynchronization between OS, BMC, andother components like the ATCA ShelfManager. For example, individual bladescan run without battery (NEBS compliance)but acquire the time from the ShelfManager upon startup.To conclude, our robust and flexibleIPMI offering is fully deployed inmission-critical rollouts worldwide.Advantech’s ability to adopt new featuresrapidly helps customers achievetheir platform management goals forimproved uptime and services, providinggreater reliability in HA platforms.As we actively engage with moreplayers in the Enterprise and Security,we’re excited about the introductionof additional enhancements later thisyear that will simplify their approach toATCA systems.22 | Summer 2012 | CompactPCI, AdvancedTCA & MicroTCA Systems

GEIntelligent PlatformsEnabling and securingthe connected warfighterip camera360°situationalawarenessgigabit ethernet (copper)10 gigabit ethernet (fiber)10g switchip cameradvr/dasactive protectionsystemincoming roundsensor arrayip cameraethernetswitchsensorprimary sightsensornetworknodesensorvideo processingsystemauxiliarysighthull/turretcomputersToday’s armed forces are embracing an “everythingover Ethernet” approach in building a network-enabledbattlefield. Modern military vehicles have become theleading edge of that tactical network. GE has the products and experienceto digitize sensors, standardize vehicle networks, and exploit datawithin harsh, space-constrained environments. Our COTS products reducecomplexity, risk and cost, and enable rapid deployment of your modernizedplatform. We have the full portfolio of solutions to turn disparate systems into aseamlessly connected network to connect warfighters like never before.datarecordersensorFor whitepapers and application details, visit:defense.ge-ip.com/milcomdataradiorouter/firewallsensorwin-tjc4isrdataradiorf antenna© 2012 GE Intelligent Platforms, Inc. All rights reserved.All other brands or names are property of their respective holders.