1 / 21

Multi-level Simulation of a Real Time Vibration Monitoring System Component Bryan Robertson/EI31

Multi-level Simulation of a Real Time Vibration Monitoring System Component Bryan Robertson/EI31 NASA/Marshall Space Flight Center. Health Management System Overview RTVMS Design Overview Simulation Environment Simulation Details Summary. Health Management System Overview.

frey
Download Presentation

Multi-level Simulation of a Real Time Vibration Monitoring System Component Bryan Robertson/EI31

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Multi-level Simulation of a Real Time Vibration Monitoring System Component Bryan Robertson/EI31 NASA/Marshall Space Flight Center

  2. Health Management System Overview • RTVMS Design Overview • Simulation Environment • Simulation Details • Summary

  3. Health Management System Overview • A Real-Time Vibration Monitoring System (RTVMS) was developed by MSFC and currently operates at the Stennis Space Center (SSC) during Space Shuttle Main Engine (SSME) test firings. • The RTVMS provides real-time vibration analysis and health monitoring capabilities during engine operation by producing vibration spectral data from critical SSME Components. This vibration analysis provides the capability to activate a vibration flight redline for engine high pressure turbomachinery. • For the RTVMS time resolution is critical. Parallel processing and multiple DSPs are required to perform the FFTs and health algorithms required. • In early 2000 the MSFC Shuttle Main Engine Project Office decided to pursue implementation of the RTVMS technology for Space Shuttle Flights. This advanced flight RTVMS would contain all the features of the current SSC ground RTVMS system but would also include additional algorithms that would also evaluate the vibration data in the phase domain. • The fist step toward implementing the flight RTVMS systems was to develop a ‘flight-like’ health management system that incorporated the RTVMS and other existing engine monitoring systems. This system is called the Health Management Computer – Integrated Rack Assembly (HMC-IRA). The RTVMS design for the HMC-IRA will be covered in this presentation.

  4. Health Management Computer – Integrated Rack Assembly (HMC-IRA) • Ground based system – designed as ‘flight-like’ while maintaining low cost. • Simulates an Advanced Health Management System (AHMS) Shuttle Main Engine Controller flight system processing environment. • Provides a Real Time Vibration Monitoring System (RTVMS) design that can transition to a flight system design with only form-fit modifications. • Provides flexibility for growth and alternate software configurations and hardware additions. • Provide interfaces for: • AHMS Space Shuttle Main Engine Controller (SSMEC) • Space Shuttle Main Engine (SSME) sensors • Stennis Space Center (SSC) Data Acquisition System. • Development of three Brassboard HMC-IRA and three Special Test Equipment Units • Planned operation with a SSMEC during SSME Hot-fires at SSC • Supports SSMEC operations at the MSFC SSMEC Hardware Simulation Lab • Supports software development at the Rocketdyne Controller Simulation Lab. • System Development and Verification is complete on all units and are currently waiting for Integration into the SSC facility. AHMS(Phase 1) SSME Block II Controller

  5. The HMC-IRA consists of custom and COTS components. • Three PowerPC 603 processors • Ten TMS320C40 DSPs on two RTVMS boards. • All DSPs interconnected through serial ports. On-board and board-board. • All 10 DSPs receive the sensor data from the two analog cards simultaneously. • DSPs can be configured in a variety of parallel processing configurations. • All DSPs have access to the main VME bus. • 1.5Gbyte Non-volatile Memory board • Two Analog cards • SSMEC, SSME, and SSC interfaces • Dual sampling rates • VME and DSP serial interfaces. • Three SSMEC RS485 High Speed Serial Interfaces RTVMS Basecard and mezzanine Radstone EP1A-8240 Radstone EPMCQ2R PMC SEAKR NvM • Customized VME backplane supporting serial communication channels between RTVMS and analog boards.

  6. Real Time Vibration Monitoring System (RTVMS) Overview • First EI31 Multiple/Parallel Processing Digital Signal Processor (DSP) Design. • First design to use System level simulations • Design was required to have a path to flight. • Designed with commercial version of flight quality components. • EEE Parts evaluation performed on selected flight components • Challenging Printed Circuit Board Design • First 16 layer board. Previous ED16 designed board had max 14 layers. • Most densely populated board routed by ED16. 1012 components for baseboard, greater than 1800 total. 1.5 to 2 times more components than any previous ED16 design. • 28mil Via sizes utilized for the first time (previous size was 40mil • Developed PCB procurement standards now being used by other projects

  7. Real Time Vibration Monitoring System (RTVMS) Design • A32/D32 VME Master w/ Block and RMW transfer capability • A24/D32 VME Slave  8K x 32 Dual-Port SRAM • 5 Texas Instruments 320C40HFHM50 DSPs (4 for algorithm processing and 1 for communications) • 512K x 32 (2Mbytes) of SRAM on Local Bus of each DSP • 512K x 32 (2Mbytes) of SRAM on Global Bus of each DSP • 32K x 32 of EEPROM on Global Bus of each DSP for boot operations • 8k x 32 Dual-Port SRAM on Global Bus that is shared between the DSPs • Communications Port Interface with EADIFA and EADIFB boards • Communications Port Interface between the DSPs • 2 Actel A54SX32A FPGAs for various logic applications

  8. Elements of Simulation Environment – VHDL VHDL CASE addr IS WHEN "01000" => flash <= '0'; WHEN "01001" => flash <= '1'; WHEN "01010" => mps_pwr <= '1'; WHEN "01011" => mps_pwr <= '0'; WHEN "01100" => eng_pwr <= '1'; WHEN "01101" => eng_pwr <= '0'; WHEN "01110" => x_tvc_en <= '0'; WHEN "01111" => x_tvc_en <= '1'; VHDL logic implemented in 2 Actel A54SX32A FPGAs Behavioral (Functional) Simulation Synthesize & Target (Actel,Xilinx,Altera,etc.) Timing Simulation Place & Route (Structural VHDL)

  9. Elements of Simulation Environment – Synopsys Software Models • Licensed models of components or protocols such as memories, logic circuits, VME communication, etc. • - Used to verify interfacing properties such as setup and hold timing, bus contention,etc. • - Have some adjustable parameters to optimize for application • Not suitable for complex circuits such as DSPs if high-fidelity simulations required VHDL Software Model Representation entity and_gate is port ( x,y : in std_logic; z : out std_logic ); begin end and_gate; architecture a1 of rtvms_int_blk is begin z <= x and y; end; Gate Level Component x z y

  10. MSFC Network XPLORER MS-3X00 ModelSource XPLORER MS-3X00 ModelSource Elements of Simulation Environment – Synopsys Hardware Model • Built by Synopsys using actual chips and interfaced to Hardware Modeler • - Actual silicon communicates with simulators • - Much faster than software models • - Elementary software code can be executed on microprocessors • Design and Simulation Tools reside on individual office computers Hardware Model Operation in B222 Lab Designer’s Office TMS320C40 DSP PC Interface to Hardware Models Designer’s Office HDL Simulator Fiber Optic Link Ethernet Link Designer’s Office

  11. Mentor Graphics Design Capture Environment • Where the Elements of Design are “connected” together CASE addr IS WHEN "01000" => flash <= '0'; WHEN "01001" => flash <= '1'; WHEN "01010" => mps_pwr <= '1'; WHEN "01011" => mps_pwr <= '0'; WHEN "01100" => eng_pwr <= '1'; WHEN "01101" => eng_pwr <= '0'; WHEN "01110" => x_tvc_en <= '0'; WHEN "01111" => x_tvc_en <= '1'; Hardware Modeler Symbols HDL Over 14,000 Fully Functional Models -- Memories -- Standard MSI/LSI Logic -- Bus functional microprocessors/DSP -- Bus functional microcontrollers -- Bus Interfaces (VME, PCI) -- Memories can be loaded with software to allow full board level simulation Software Model Library Symbols

  12. ModelSim Simulation Environment VHDL Simulation Hardware Modelers Schematic Capture Over 14,000 Fully Functional Models -- Memories -- Standard MSI/LSI Logic -- Bus functional microprocessors/DSP -- Bus functional microcontrollers -- Bus Interfaces (VME, PCI) -- Memories can be loaded with software to allow full board level simulation CASE addr IS WHEN "01000" => flash <= '0'; WHEN "01001" => flash <= '1'; WHEN "01010" => mps_pwr <= '1'; WHEN "01011" => mps_pwr <= '0'; WHEN "01100" => eng_pwr <= '1'; WHEN "01101" => eng_pwr <= '0'; WHEN "01110" => x_tvc_en <= '0'; WHEN "01111" => x_tvc_en <= '1'; HDL Software Model Library

  13. Synopsys Software Models Symbols Synplicity/Leonardo Synthesis Tools Functional Or Synthesized VHDL Code Re-Synthesize Synopsys Hardware Models Symbols Mentor Schematic Entry Compile Design Modify VHDL Code If Necessary Mentor Design Capture Generate VHDL Netlist FPGA Libraries Compile for Simulation Run Simulations Verify Design Parameters Hardware/Software Libraries Synopsys Mentor Simulator RTVMS Design Flow

  14. Simulation Test Code Details • C test code was executed on the TMS320C40 Hardware Model(not real time) • Each TI DSP contained four 32K x 8 EEPROMs for boot operations • The code was written and compiled utilizing TI’s C40 Code Composer • The compiled code was partitioned into 4 sections utilizing the hex 30 command • hex 30 EEPROM.out -i -romwidth 8 -memwidth 32 • -o EEPROM.lo1 -o EEPROM.lo2 • -o EEPROM.hi1 -o EEPROM.hi2 • Each 8-bit EEPROM file was then converted to Intel hex format utilizing a custom conversion program(Intel_Hex_MIF_Conv.exe) • Each EEPROM Synopsys software model instance in the Mentor Graphics Design Capture tool contained a memory file attribute that linked the model with a corresponding EEPROM file • At boot in the ModelSim environment, each DSP Hardware Model instance would execute the code located in its corresponding EEPROM files

  15. RTVMS Component Level Verification • Functional Simulations were initially utilized to verify the Hardware Model and its surrounding logic. The simulations included.. • Ability to boot correctly from EEPROMs • 512k x 32 SRAM Access(Global and Local) • The timing of the simulation could be manipulated the following two ways: • TMS320C40 Hardware Model timing attribute • Synopsys Logic Memory Models timing attribute • Various simulations were run where the timing attributes were modified to simulate multiple conditions.

  16. RTVMS Board Level and FPGA Verification • Once the Hardware Model and its surrounding logic were verified, the simulations were expanded to include RTVMS Board and FPGA verification. The simulations included.. • MGBC FPGA Register Access • MGBC FPGA Watchdog Operation • Dual-Port SRAM Access with arbitration inside the MGBC FPGA • DSP to DSP Comport Operations • Once the functionality was verified, the FPGA code was synthesized and the simulations repeated multiple times. The timing of the simulation could be manipulated in three ways in the: • TMS320C40 Hardware Model timing attribute • Synopsys Logic Memory Models timing attribute • Synthesized FPGA logic delays (min,typ,max)

  17. HMC-IRA System Level Verification • The system level verification consisted of the following components to simulate multiple boards in a VME chassis: • 2 RTVMS Board Designs(Master and Slave) • 1 EADIF-A Board Design(Slave) • 1 VME Hardware Verification Logic Model(Master,Slave,System Controller) • PCL code was written for the VME Hardware Verification Model to operate as a System Controller • Functional and Timing simulations were executed to verify the following: • RTVMS VME Accesses(Single, Block, and Read-Modify-Write) of the System Controller • Execution of VME Interrupts • On-board VME Arbitration • VME Access of the RTMVS DPSR by the System Controller(RTVMS as a Slave) • EADIF-A to RTVMS DSP Comport Operation

  18. Advantages of Board and System Level Simulations • Box and Board Level Simulations Provide a Unique Capability • More Complex Design Capability • Lower Cost – Fewer Design Iterations and Reduced Debug Time • Higher Reliability due to Timing Analysis Capability • The potential to substantially decrease development time over traditional methods • Test code used as a foundation for the development of system software that can occur in parallel to hardware development.

  19. Disadvantages of Board and System Level Simulations • Simulation != Analysis • Simulations are limited to small time segments • Simulation tools are expensive • Upfront design time increased (Longer time to initial product)

  20. Summary • The HMC-IRA RTVMS boards have completed all board level and system level verification tests and are waiting for delivery to the Stennis Space Center. • During testing no design errors with the 15 Engineering Unit and Brassboard were encountered. • Only slight modifications to the design was made between the Engineering Unit and Brassboard Unit boards. These changes were for routing purposes. The Engineering Unit boards met all requirements , re-spin of board would not have been required • Because of the detailed simulations and schedule time allocated for performing the simulations, no functional or timing errors have occurred. • Only one printed circuit board assembly had a manufacturing issue. Only one significant component failure with a SRAM.

More Related