170 likes | 295 Views
Overview. State of the Art Hardware First Approach Hardware/Software Co-Design Emulation Based Methodology The Approach as a Two–Stage-Design Flow The Spyder tool set Results and Experiences Future Work: Distributed Emulation Environment. Hardware First Approach.
E N D
Overview • State of the Art • Hardware First Approach • Hardware/Software Co-Design • Emulation Based Methodology • The Approach as a Two–Stage-Design Flow • The Spyder tool set • Results and Experiences • Future Work: Distributed Emulation Environment
Hardware First Approach Most commonly applied methodology: Partitioning mostly based on developer‘s experience and intuition Software design starts after complete hardware implementation • Major Disadvantages: • Risk of design faults: System can not be tested at an early state • Design delay between hardware and software design
Hardware / Software Co-Design Specification tries to build a complete description of the system‘s behavior Algorithm based concept Verification of system design at an early state in the design flow Problems: Insufficient knowledge about functional behavior of IP-cores No unrestricted substitution of HW/SW components for real applications (few degrees of freedom for micro controllers)
Conclusion about these approaches Problems: • Hardware first approach: • No Verification of the system design at an early stage of the design flow process • HW/SW Co-Design: • limited by insufficient knowledge about internal behavior of IP - cores • Restricted degrees of freedom Both methodologies are unsuitable for developing embedded systems consisting of only a few, but highly complex components.
New: Emulation Based Methodology Functional Specification • Stage 1: System Design by Evaluation Not restricted to well-known components Components analyzed by criteria like functionality, complexity, or testability Source for these criteria: Data sheets, manuals, ... Stage 2: Validation by Emulation Stage one influenced by knowledge and experience of the system designer validation avoids fatal design errors Initial Partitioning and pre-selection Stage One: Evaluation Stage Two: Emulation Stage Two: Emulation pass ? pass ? no no yes yes System Integration and Test K. Weiß: Architekturentwurf und Emulation eingebetteter Systeme. Ph-D. Thesis, University of Tübingen 15.Oktober 1999
Stage One: Evaluation Decision-Making Criteria and Ranking: Micro controller is most important component (only a few types available) determines basics like bus interface, power supply, etc Example Bus Interface: Best case: complete compatibility of the busses of the Microcontroller and component Worst case: Highly complex bridges are necessary construct a ranking system to choose the most suitable component
Stage Two: Validation by Emulation Spyder Virtex X2: Designed for emulating application specific hardware or testing IP-Cores Spyder Core P2: Designed for emulating software components in a real time environment (VxWorks ready)
Spyder-Virtex-X2 SPYDER-VIRTEX-X2/XCV300..800
C-API-Routines for NT 4.0 connection to CORE-tools SSRAM 256k x 32 or SDRAM 4M x 32 SSRAM 256k x 32 or SDRAM 4M x 32 Spyder-Virtex-X2 serial EEPROMs 6 x 1Mbit arbiter external FPGA configuration header CPLD XC95144xl configuration 86 Xilinx-Virtex-FPGA I PCI-interface microcontroller XCV300...XCV800 PCI - SLOT 30 PLX-PCI9080 86 32 II BGA 432 now available extension header I and II power supply + 2,5V / 10A + 3,3V / 3A high density logic analyzer connectors
high density logic analyzer connectors EPROM 1 M x 8 RTOS: VxWorks BSP: TCP/IP, RS232, Flash EMBEDDED-BIOS HDI monitor GNU-C environment Flash 1 M x 32 16MB SDRAM 10Base2 Ethernet SH3 7709A or 7729-DSP 133/66 MHz CAN CPLD Buffer Extension headers JTAG SER 0:2 connection to FPGA-tools 86 86 Spyder-Core-P2
Experiences Automotive Industries: Porting the VxWorks RTOS Hardware First Approach: Emulation Based Methodology: Complex hardware prototype: Multiple points of failure Limited debugging facilities Significant design delays Emulation platform Spyder: Hardware tested Good debugging facilities Comfortable developing environment Using the Spyder System, it was possible to port VxWorks within two weeks
Future Work: Spyder - Virtex -X3 Scalable Emulation System Works in stand-alone mode: uses TCP/IP for configuration and communication: VxWorks based firmware (Hitachi SH3 architecture) Appears as a black box to the user Internet technology enables a virtual distributed laboratory.
The Distributed Laboratory • Situation Different know-how of the parties working together Developers only know a part of the whole design Communication between experts is very time consuming. Approach: „transparent“ administration / upgrade via the internet
The Distributed Laboratory Example: One team designs a hardware IP- Core component The IP-Core is stored at Spyder- Virtex-X3 at a local file system System integrators can use this component Ethernet Flash Memory SDRAM File System File System TCP/ IP Application FPGA Driver FPGA Software Architecture of Spyder-Virtex-X3 The hardware designer group can upgrade the IP-Core design via internet (Bug Fix on Demand) C. Nitsch, U.Kebschull: Rekonfiguration zur Laufzeit unter VxWorks, AES 2000, Karlsruhe
The Distributed Laboratory FTP Based Interface: Modified FTP Server “Special Directories” System independent Spyder-Virtex-X3 can be managed remotely.