A Seamless Tool Access Architecture from ESL to End ProductAlbrecht Mayer
Infineon Technologies AG, 81726 Munich, Germany
albrecht.mayer@infineon.com
Abstract
Tool access to processor cores is needed from thefirst ESL (Electronic System Level) models, over chip
design simulation, silicon on wafer, silicon on test
board and prototype systems up to the real end
product. Tools are in particular debuggers, but also
performance optimization tools and domain or system
specific tools. This paper will start with applications
and requirements, discuss then the basic Tool AccessArchitecture (TAA) and finally describe a solution in
more detail, which has been implemented (productiveor at least prototypes) for all development stages
from ESL, chip simulation and silicon up to theautomotive target system.

1. Introduction
The motivation for a unified tool access are thesignificant cost and time to market benefits due toreuse and the possibility to execute tasks earlier.
Systems are getting more and more complex. A
multi-core SoC used within a demanding real-timesystem is now standard system architecture in many
application areas. The other trend is the shift offunctionality from hardware to software. Bothtogether require that software is already at least partly
developed in the concept phase based on ESL models.
This is beneficial for proving the hardware andsoftware concepts, but requires that the standard
software tooling is available also for ESL models.
Since there are in such projects already more software
than hardware developers, and this shift is still goingon, this is an interesting market for tool vendors.
However it needs to be understood, that the rules
come from the software side, where the reference isthe free GNU compiler and not a multi 100k $ HDL
synthesis tool license.
For complex system design the development flow
starts with software development on the ESL modeland ends with debugging the target system. For thesedevelopment steps the tool access to the SoC serves
not only as the software debugger connection, it is thekey entry point for analyzing the whole system. A
tool architecture, which allows using the same tools
over the whole development process, will
significantly reduce cost and risk.

2. Applications
Beside the most obvious use case for a unified TAA,
using the same software tooling from ESL model toend product, there are also other important TAAapplications:•System and software debug and optimization•Silicon debug•

Silicon validation tests development•Tool chain debug

Table 1 shows the mapping of the TAA application tothe different development steps.

SW Dev.

ESL
Model

HDL
Simul.

FPGAProto.

Silicon/DeviceTarget
System

X

(X1)

X

X

X

X

(X2)

SiliconDebug
Silicon Val.
Test Dev.

(X3)

(X4)

(X)

X

Tool ChainDebug

(X)

X

X

X

Table 1: TAA Applications and Targets
1

Very low level software like the start-up software in the bootROM. Another special application is running known (bug-free)
software on a new hardware design (e.g. new processor pipelineimplementation).
2

Special use case is the analysis of field returns

3

Only for high-level silicon validation tests

4

For a very detailed debugging of silicon validation tests

In the following the terms “silicon” and “device” areused for the same object but for different
perspectives: “Silicon” is used when the debug of thechip hardware itself is in the focus, “device” in caseof tooling for software and system debug.

question is the abstraction and functionality of theaccess primitives. For the scope ESL to end product,
the access functionality needs to be on the level ofprocessor core run control, triggers and trace and notjust on the simple read/write target access level.

2.1 Software Development

3.1 General Requirements

For software development the tool access is needed
for the steps ESL model, possibly an FPGA
prototype, the device on an evaluation board and/or
for the final target system. Since this setup has by far
the most users, the TAA needs to support optimum
tool performance.

One of the most important requirements for the toolaccess is reliability and robustness. It is not
acceptable for the user if artifacts, created by the toolaccess, increase the complexity of debugging. Besidethe simple requirement that all information retrieved
from the target is correct, this also means that the tool
operation itself doesn’t cause any changes in thetarget’s behavior. Otherwise so called “Heisenbugs”
can be the result, which only occur, when no tool isconnected.

2.2 Silicon Debug
Functional silicon debug uses similar methods andtools as software debug. A software debugger allows
accessing all peripheral registers and supports theuser with semantic information about register bits.
Silicon debug is started on the wafer and then mainly
done with special analysis boards. However aninteresting use case is also silicon debug within the(customer’s) target system, for analyzing a potential
chip problem (field return) without desoldering.

2.3 Silicon Validation Test Development
Silicon validation tests use, beside downloaded test
programs, the access to special hidden hardware
registers (e.g. by JTAG scan chains) to stimulate andobserve special behavior. This is controlled over thechip’s tool interface by a test sequencer tool. For
developing these tests it is very important to haveparallel access to the target by the test sequencer tool
and a software debugger tool for the downloaded testprograms.

2.4 Tool Chain Debug
A reliable and robust tool connection is a mandatory
prerequisite for any kind of (test) softwaredevelopment. In particular when the first wafer comesfrom the fab, the bring-up of the tool connection is in
the critical path. A unified TAA allows preparing thisbring-up not only with an FPGA prototype but with
the HDL simulation already.

3.1.1 Cost and Performance
For devices with many different customers, likemicrocontrollers, it is very important for the silicon
vendor to have a cost effective tooling solution forevaluation boards. On the other side it needs to bepossible to offer high performance TAA implementtations for more demanding use cases.
3.1.2 Parallel Multi-Tool AccessFigure 1 shows a typical multi-device, multi-coresystem. For the applications ESL Model and Target
System, the TAA needs to support such a scenario.
For the other applications (Table 1), the (multi-) toolaccess is on device level. Please note that there can be
not only several instances of a core, but also different
core types, coming from different IP vendors andbeing supported by different tool vendors.
ToolCore ATool
Core B

Tool I/FSystem
Device A0
CoreA03. Tool Access Architecture Requirements
The scope of the unified TAA is from ESL to end
product. This range can only be covered, when thetool interface is on software level. The second generalTool
Core CCoreA1

Device A1
CoreB0CoreA0

Device B0
CoreB0CoreA1

Figure 1: Multi-Device, Multi-Core SystemCoreA0CoreC03.1.3 Standard Interfaces
For reducing development effort and cost, standards
are always the preference, if they provide thenecessary functionality.
3.1.4 Ownership and Testability
It is very important that all components of the TAA
have a clear ownership (silicon vendor, tool partner,etc.) and have straightforward unambiguousinterfaces, which allow a rigorous testing. Only by
careful analysis of what’s needed for covering all
TAA application features, the interfaces can be
reduced to the minimum complexity.

3.2 Special Requirements
Beside the general requirements, which cover theSoftware Development application, there are specificrequirements for other TAA applications and TAA
targets (Table 1).
3.2.1 ESLAs already mentioned, the ESL Model application
enforces that the TAA tool interface functionality ison the level of core run control, triggers and trace inaddition to read/write accesses. The reason for this isthat ESL models have abstract representations of theon-chip debug IP, which are more powerful andsimulation speed friendly. Without the ESL model
requirement, the unified TAA could be restricted toread/write target access without more detailed
semantics.

Another ESL specific requirement is shown inFigure 2. The system integrator will be in a situation,
to integrate models from different vendors (differentcolors in Figure 2), connected to tools from different
tool vendors. Silicon Debug
Silicon debug requires additional special accessmethods for hidden test registers. Usually these test
registers are implemented as on-chip JTAG scanchains. So the TAA needs to support a native JTAG
scan access beside the normal, address based device
access methods.
3.2.2 HDL Simulator
The HDL (Hardware Description Language) model ofa chip behaves like the real device, except that it isvery slow. The TAA needs to take this into accountfor instance with configurable timeouts.
Since such simulations usually run on Linux computefarms whilst the tool is on a Windows PC, the TAA
needs to support connecting these two domains over aLAN.
3.2.3 End Product Debug
Due to cost and space constraints, the end productdoesn’t have in most cases a tool connector (e.g.
JTAG I/F). For getting access to such targets, theTAA needs to abstract the physical interface andsupport tool access across any type of physical device
interface (CAN, USB, etc.), even shared with thetarget application.

4. Tool Access Architecture (TAA)
The basic tool access architecture is to have a genericstandard interface for the different tools and a layered
implementation which will differ for the different
stages (“Targets” in Table 1) of the systemdevelopment flow.

4.1 TAA Block Diagram
Figure 3 shows the block diagram for such a generic
TAA with the software and hardware layers fromdevice to tool.
Figure 2: Multi-Vendor IP-Model System

The TAA in Figure 3 encapsulates device type andphysical device connection type dependencies in avery low layer. This hides for instance specific startup behavior of devices with e.g. on-chip voltage
regulators. Since such a device’s start-up behavior
can require hard real-time operation from the tool, it
is even mandatory to handle it on this level.

Figure 3: TAA Block Diagram
The device Access HW in Figure 3 can be a simple
and cost effective USB to JTAG converter chip or a
powerful microcomputer with FPGA accelerator forthe physical device connection (JTAG, CAN, etc.) as
the other extreme.
The Device specific Layer converts the tool requests
like “read X bytes from address Y” in the device
specific physical connection command sequences.
The device independent communication with Clientsis handled by the Server Socket and the Client Socket
Layers respectively. In case of the powerful Access
HW, the Server Socket and the Device specificLayers can be running on the microcomputer as well,when the connection to the host computer is Ethernet.
The layering on the Client/Tool level starts with theTool itself on top, which accesses the target acrossthe Core (type) specific Layer. This layer translates
requests like “set a SW breakpoint” into the core
specific sequence of register and memory accesses.
This layer is core type specific, but it is independent
from the physical device connection. Only for ESL
models usually another implementation of this layer
is needed. In this case the Core specific Layer
implementation can be even to a great degree coretype independent, when the on-chip debug resources
have the same abstract representation in the ESL
model.

4.2 TAA Concept Considerations
One of the guiding principles for the TAA was toencapsulate specifics as much as possible locally, sothat higher layers can stay generic and straightforward. The art is on the other side to avoid making
specific but interesting features of the target notaccessible anymore due to the restrictions of such astandard interface.

When the device connection is established, allaccesses from the higher layers are memory mapped.
This is natural for memory mapped registers andmemories but it can be also expanded by using virtual
addresses for specific accesses and operations. So thesame infrastructure and communication scheme canbe used for very different purposes. This scheme
needs to be extended by the concept of atomic
transaction lists. Such a list will be executedcompletely without being interrupted by requests
from other Clients/Tools.

5. Infineon’s DAS and MCD API based TAA
The DAS (Device Access Server [1]) architecture wasdesigned for multi-device multi-core systems withvery demanding emulation requirements. It is broadly
used within Infineon for microcontrollers, but also
outside of Infineon it has been adopted in the OCP-IP
Debug Interface Specification.
The goal of the DAS architecture is to provide one
single interface for all types of tools, which fulfills all
performance and reliability needs.
The tool interface is on software level (DAS API) and
implemented in a generic DLL. It provides theabstraction of the physical device connection, whichbecomes just a parameter value in the connection
setup phase. During operation the physical connection(e.g. JTAG for real device or directly for C-models) is
fully transparent for the tool. On DAS API level thephysical device connection is represented by address
based accesses (DAS Transaction Lists) andprioritized, stream based data exchange (DASChannels).
Recently the MCD API support has been added on
top of the proven DAS API. The MCD API wasspecified within the SPRINT project [4] with thepartners ARM, Infineon, Lauterbach, NXP,
STMicroelectronics and TIMA. It fulfills exactly therequirements specified in section 3. Figure 4 shows
the resulting layer structure of Infineon’s TAA.

Figure 4 Infineon’s TAA Block Diagram

Figure 6: Multi-Tool Operation

At the moment most tools from tool partners accessdirectly DAS, but it is planned to make gradually thehigher level MCD API to the default interface.
In Figure 5 a setup is shown where different tools
access different devices. The Access HW is an onboard wiggler or a miniWiggler, which supports
JTAG, DAP and SPD. DAP (Device Access Port) is awell accepted Infineon automotive tooling standard
interface which enables a high-speed long thin cable.
SPD (Single Pin DAP) is the most cost effective(single device pin) tool connection variant.

The last example in Figure 7 shows that the Infineon
TAA hides completely the physical device connectionand device representation (real silicon or HDLmodel). With a Lauterbach debugger it has been
demonstrated that beside normal miniWiggler accessto a 32-bit TriCore microcontroller also the accessover an XCP [5] slave and even to the HDL model,
running on a simulation computer is possible. Over
the MCD API, all these three devices behave exactly
similar, except that the response from the HDL model
device is very slow (ca. 10-20s) for a single step

Host PC
TriCoreTool

XC800
Tool XC2000

Compute Farm

Host PC

Tool
TCP/IP

Target System

HDL
Simulator
TriCoreLANTool

UDASServer
TCP/IPUSBminiWigglerDAPor JTAG

TriCoreEvaluation Board
XC2000
On-Board
Wiggler
JTAGUSB
miniWiggler

SPD, DAPor JTAG

Automotive ECU

UDASServer
Ethernet

XCP
Slave

XC800

Figure 5: Multi-Device Operation

USB

TriCoreBoard
miniWiggler

In Figure 6 a device is accessed by two tools. In thisexample, one of them is located on a remotecomputer. The use case behind is debugging ofsilicon validation tests, which are executed by the test
sequencer tool [5]. Another use case example isdebugging in parallel to automotive measurement.

DAP orJTAG

DAPor JTAG

TriCoreFigure 7: Abstraction of Device and Connection
The Infineon TAA implementation uses a pragmatic
approach concerning configurability. In relation to achip design project, the adaptation of tool accesscomponents is negligible. So it is acceptable tomodify TAA components (Core specific Layer,
Device specific Layer in Figure 4) directly (C/C++code) instead of developing highly complex
configurable components.

6. Conclusions
A unified Tool Access Architecture for different
device types (e.g. 8, 16 and 32 bit microcontrollers),
different physical interfaces (e.g. JTAG, CAN, etc.)and different device representations (C-model, HDL
simulator, FPGA and silicon) has significant benefits
for the silicon vendor, customers and tool partners.
These benefits are cost and risk reduction by reuse
and the possibility to execute tasks earlier withoutprohibitive effort. This has been proven Infineon
internally using Infineon’s own DAS tooling. With
the recently released MCD API a standardized toolinterface is available now, which allows to cover thefull range from ESL to end product.

7. References[1]

www.infineon.com/DAS[2]

MCD API V1.0 specificationhttp://www.lauterbach.com/mcd_api.html[3]

OCP-IP Debug Interface Specification V1.0
www.ocpip.org[4]

SPRINT Project www.sprint-project.net[5]

European patent EP1349073B1, “Control system”[6]

ASAM MCD-1.XCP standard , “The Universal
Measurement and Calibration Protocol Family”
http://www.asam.net