1 / 10

Describing target hardware in debuggers

Describing target hardware in debuggers. Aaron Spear DEBUG TECHNOLOGIES ARCHITECT ACCELERATED TECHNOLOGY DIVISION Feb 2006 DSDP Meeting/Toronto. Agenda. Common needs for debuggers Quick look at AT’s proprietary solution Existing standards/SPIRIT Extending SPIRIT for debug use.

Download Presentation

Describing target hardware in debuggers

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. Describing target hardware in debuggers Aaron Spear DEBUG TECHNOLOGIES ARCHITECT ACCELERATED TECHNOLOGY DIVISION Feb 2006 DSDP Meeting/Toronto

  2. Agenda • Common needs for debuggers • Quick look at AT’s proprietary solution • Existing standards/SPIRIT • Extending SPIRIT for debug use Nucleus EDGE Architecture - company confidential

  3. Debugger features tied to hw details • Board/connection information (e.g. JTAG scan chain info) • Registers (native, coprocessor, peripherals) • Memory maps • Help building apps/validation • HW tools (e.g. memory testing, flashing) • Aid the debugger (e.g. ROM stepping) • Initialization Nucleus EDGE Architecture - company confidential

  4. What is SPIRIT missing for debugger use? • Core internal register information • Register use information (does reading a register change its contents? Important for a debugger!) • Non-contiguous bitfields? Nucleus EDGE Architecture - company confidential

  5. Register specific information we need: • id, alternative id’s (e.g. “R15”, “R15_irq”) • bit width • register type (floating point? fixed point?) • access restrictions (RW) • access hints/side effects • volatile contents • reads are destructive • writes may change state/invalidate other memory • dependencies (visibility depends on another register/bit field) • bit fields • which bits (non-contiguous!?) • value to text mapping • formulas/masks for values • default formatting hints (hex vs decimal) • access (RW) Nucleus EDGE Architecture - company confidential

  6. Memory info we need? • address spaces • id (“Memory”, “IO”,”DATA”, “INST”) • unit size (e.g. 8 bits) • unit count (e.g. 2^32) • Memory maps (core specific/shared) • region name (“DRAM”, “FLASH”) • space reference • offset in space (units) • unit count • Access flags (RWXV) • Required access sizes (none, 16 bit write?) • Memory type (RAM, Flash information) Nucleus EDGE Architecture - company confidential

  7. What is SPIRIT? SPIRIT stands for: “Structure for Packaging, Integrating and Re-using IP within Tool flows”, • Standard schema for description of HW IP blocks • Standard interfaces for IP creation and configuration scripts (“generators”) • Standard interfaces for “flow based” Electronic Design Automation (EDA) tools Nucleus EDGE Architecture - company confidential

  8. What is SPIRIT used for today? • Vendor neutral description of IP blocks for use by SoC design tools • Interconnection of HW IP on an SoC • Routing of signals between IP blocks • Cores, peripherals, buses • Focused on creation of SoC Nucleus EDGE Architecture - company confidential

  9. What does SPIRIT have that is cool for debugger vendors? • Standardized description of memory maps • Address Spaces • Buses/bridges between spaces • Memory mapped registers (peripherals) • Bit fields within registers If it was the memory map used in creation of the SoC, it is going to be correct! Nucleus EDGE Architecture - company confidential

  10. Thank You! www.acceleratedtechnology.com

More Related