+ All Categories
Home > Documents > 11 Using SPIRIT for describing systems to debuggers DSDP meeting February 2006 Hobson Bullman –...

11 Using SPIRIT for describing systems to debuggers DSDP meeting February 2006 Hobson Bullman –...

Date post: 29-Dec-2015
Category:
Upload: claribel-mason
View: 214 times
Download: 0 times
Share this document with a friend
13
1 1 Using SPIRIT for describing systems to debuggers DSDP meeting February 2006 Hobson Bullman – Engineering Manager Anthony Berent – Debugger Architect ARM - Development Systems © ARM Limited 2006. All rights reserved.
Transcript

11

Using SPIRIT for describing systems to debuggers

DSDP meeting February 2006Hobson Bullman – Engineering Manager

Anthony Berent – Debugger ArchitectARM - Development Systems

© ARM Limited 2006. All rights reserved.

222

OverviewDebuggers need to understand the system they are debugging.

___Putting the descriptions in data files provides flexibility.

___Using an open, standard, format for such data files allows the

files to be created by SoC designers and shared between tools.___

SPIRIT is an open standard that can describe systems at the appropriate level of detail.

___ARM will be using SPIRIT in its debug tools, and promoting its

wider use in debug tools.

333

The problem Embedded systems used to be reasonably simple. e.g.:

1 processor

1 system bus

Etc.

Telling the debugger about such systems was reasonably simple.

Now: Many processors

Many busses

Complex memory maps

So how do we debug complex systems? We need the ability to debug all the processors, and to trace all the

processors and busses

444

Debug hardware for complex systemsA complex system needs complex debug hardware

E.g. CoreSight is the ARM hardware solution to debugging complex systems:Consistent architecture for debug and trace devices.Bus structure allows all devices to share a single debug control port, and a single trace port.

But there is still a software problem:

How does the debugger know what components exist in the system?

How does the debugger know how the components are connected together?

How does the debugger know how to access the components?

Having lots of debug components in the system just magnifies this problem.

ARMcore

DSP

AMBA AXI/AHB

AHB trace

Cross

Trigger

Interface

Cross

Trigger

Interface

DAP

CoreSight Debug

ETM ETM

Tracebuffer

Trace bus (ATB)

Traceport

Funnel

CoreSight Multi-source

Trace

JTAG

Debug bus (APBv3)

RAM ROM I/Odevice

ARMcore

I/Odevice

Cross trigger matrix

555

Cross

Trigger

Interface

Cross

Trigger

Interface

ARMcore

What does the debugger need to know? Programmers’ model:

System components

System busses

Base addresses

Device registers

Debug access description: Debug access to processors

Other debug devices

Debug interconnections

DSP

AMBA AXI/AHB

AHB traceDAP

ETM ETM

Tracebuffer

Trace bus (ATB)

Traceport

Funnel

JTAG

Debug bus (APBv3)

RAM ROM I/Odevice

Cross trigger matrix

0x10000000 0x0 0x30000000

Reg 1

666

Data driven debugger configuration With a large range of such complex systems it becomes

impractical to explicitly build support of each system into the debugging tools.

Far better to build in support of the individual components, and to use a data file to describe the system

If the data file format is open then SoC designers or debugger users can create their own descriptions of new SoC

Ideally multiple tools, even from different vendors, should be able to read the same data files.

777

SPIRIT and debugger configuration A SPIRIT system description can contain the information the debugger

needs: Component list. Component interconnection. Physical address maps. Some extra usage conventions (e.g. names of debug interfaces) needed:

Under development by ARM, will be made publicly available.

Open standard, so the same descriptions can potentially be used by many tools. Including ARM and non-ARM debug tools.

Reasonably simple XML format. Hierarchical designs supported:

This allows separate subsystems to be described independently.

Standard SoC design tools are starting to support the creation and use of SPIRIT descriptions: Hence the SPIRIT description can be easily generated during SoC design.

888

Typical data flows

ETMCS for Tiger

DAP for Tiger

AHB TraceFunnel

ETBCS

EDA/ESL Tools

Component I/O and memory map information

as a SPIRIT XML File

ETMCS for Tiger

DAP for Tiger

AHB TraceFunnel

ETBCSIP Components

Other topology tools:

• Manual file generation

• Proprietary tools

• Autodetect from SoC

Emulator

ETMCSDAP

AHB Trace

Funnel ETBCS

DSP

Topology and System Memory Map Description

as SPIRIT XML

Reads debug access descriptions from SPIRIT

files

DebuggerReads programmers’ model from SPIRIT

files

IP ve

ndorS

ystem

designer

Softw

are

developer

999

Part of a SPIRIT design description<spirit:design xmlns:spirit=http://www.spiritconsortium.org/XMLSchema/SPIRIT/1.1 xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.spiritconsortium.org/XMLSchema/SPIRIT/1.1 http://www.spiritconsortium.org/XMLSchema/SPIRIT/1.1/design.xsd">

<!-- Name and version of design -->

<spirit:vendor>ARM</spirit:vendor>

<spirit:library>CoreSightSampleDesign</spirit:library>

<spirit:name>Sample_design</spirit:name>

<spirit:version>1.0</spirit:version>

<!-- Components used by design -->

<spirit:componentInstances>

<!-- 1st ARM 1176s -->

<spirit:componentInstance>

<spirit:instanceName>Core_0</spirit:instanceName>

<spirit:componentRef spirit:vendor="ARM“ spirit:library="Cores" spirit:name="ARM1176JZFS"spirit:version="r0p0" />

</spirit:componentInstance>

<spirit:interconnections>

<!-- The processors are connected to their ETMs -->

<spirit:interconnection spirit:component1Ref="Core_0” spirit:busInterface1Ref="ETMIf" spirit:component2Ref="ETM_0“ spirit:busInterface2Ref="ProcessorIf" />

<spirit:interconnection spirit:component1Ref="Core_1“ spirit:busInterface1Ref="ETMIf" spirit:component2Ref="ETM_1“ spirit:busInterface2Ref="ProcessorIf" />

101010

111111

SPIRIT for debug standardization SPIRIT, in its current form, is useful for debug. SPIRIT consortium steering committee looking at future

activities: Extension of scope to include software debug likely. The main effect of this will be to allow consideration of debug

requirements in future extensions to SPIRIT.

Possible areas for extensions to SPIRIT to improve debug support (none yet proposed to SPIRIT consortium): Description of non-memory-mapped registers (e.g. co-processor

registers or internal processor registers). SPIRIT already supports some description of internal registers for

hardware validation. This could possibly be extended to provide descriptions suitable for software debug.

Description of interrupt structure. Explicit tagging of interfaces used for debug control

121212

SPIRIT and ARM SPIRIT descriptions are being developed for ARM IP:

Including processors, CoreSight components, busses.

ARM EDA tools support SPIRIT

ARM is a leading participant in SPIRIT consortium.

131313

Conclusions SPIRIT provides a vendor independent way of describing

complex systems.

SPIRIT descriptions can contain the data needed to allow such systems to be debugged.

Adoption of SPIRIT descriptions for debug will allow easy multi-sourcing of both components and debug tools

ARM is developing support of SPIRIT in their debug tools, and is leading discussion within the industry on the potential use of SPIRIT as an open standard for debug target description


Recommended