1 / 17

Overview

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.

adin
Télécharger la présentation

Overview

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. 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

  2. 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

  3. 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)

  4. 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.

  5. 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

  6. 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

  7. 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)

  8. Spyder-Virtex-X2 SPYDER-VIRTEX-X2/XCV300..800

  9. 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

  10. Spyder-Core-P2/SH3

  11. 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

  12. 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

  13. 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.

  14. 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

  15. 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

  16. The Distributed Laboratory FTP Based Interface: Modified FTP Server “Special Directories” System independent Spyder-Virtex-X3 can be managed remotely.

More Related