Processor Design and Implementation for Real-Time Testing of Embedded Systems

Walters, G.; King, E.; Kessinger, R.; Fryer, R.

17th DASC . The AIAA/IEEE/SAE , Digital Avionics Systems Conference, 1998. Proceedings., Volume: 1

Page(s): B44/1 -B44/8

What’ Problem ?

Design and implement processor that are compatible with commercial instruction sets and have specific features for visibility to facilitate to test ,debug, and maintenance of real-time processing system. These features include:– Real time Non-intrusive instrumentation(RTNI)– Behavioral Verification Technology(BVT)– Do not interfere in any way in the operation of

the system.

Introduction

The advance of combination of RTNI and BVT:– Reduces system validation time ,risk and cost.– Increasing the coverage and assurance level

The feature implemented in processor – High performance – Low power,commercial grade, or radiation hardened

Development of processor military and commercial application

Background

DOD-design embedded processors contained in avionics system have incorporated “test hooks” to facilitate the debugging of the system and software

Most of Commercial-Off-The-Shelf (COTS) have not included RTNI for real-time software application

Real time Non-intrusive Instrumentation (RTNI)

The software bug often do not appear until the system has been fully integrated and running at speed.

Real time execution causes event timing and the CPU profile to change, since it is affected by real-time interrupts, real-time task-switching,and inter-task dependencies.

Bus-based debugging system

That is blind when MP is doing in no bus cycles at system bus.

That is unable locate instruction or operand boundaries within the block of memory accessed.

This force s firmware/software developer to intrusively trap real time code.

Solve Bus-based problem

The instrumentation mechanisms must be transparent to the behavior of the software.

Transparency has typically been deemed adequate :– If the flow of addresses in program execution is

identical – If the time relationships of all software detectable

events are equivalent– i.e. interrupts,sequence of procedures run,time spent

in a process.

The debug functions of RTNI supports Trace Stop/Start on Event Single Step Software/Hardware Breakpoints Inspect/Change Memory Up to (16) Hardware traps Timers/Event Counters Event Timing Inspect/Change Registers Inspect/Change I/O port Reset/Configure Performance Monitor Enter/Exit Console Mode Reset RTNI Run/Stop

The RTNI specifics The interface is made up of :

– 8-bit command bus– 32-bits data bus– 14-bits status bus

The data bus is used to :– Specify the register number for read/write register

commends– Specify the address for read/write memory/IO commends– Specify the data value for write commends– Provide the data value for read commends– Provide the trace data when trace is enable

The RTNI specifics (cont.)

The status bus is to indicate:– RTNI can accept a new commend– Current RTNI commend complete– Current state of the microprocessor – Valid trace data– First word of multi-word trace packet– Hit/Miss status for the internal breakpoint

register

The application of RTNI

Support industry standard symbolic debugger through an Application Programming Interface (API).

Implemented as a general-purpose diagnostic port architecture which is open, scalable and consistent with commercial development tools.

The characteristics of BVT It is automated, checking against

expected results thereby eliminating the uncertainty of ad-hoc,random testing.

It is based on a measurable and enforceable specification .

It provides comprehensive specification coverage.

The characteristics of BVT

It is applicable throughout the development process as well as on the finished product.

It integrates new tests as the specification evolves or as the developer requires.

It provides repeatable and predictable test results.

It is easy to use.

The test procedure of BVT

set upthe initial state

performance the testfunction

creat ed expect result in asemi-automated method

compares the actural resultagainst the expected result

All specified behivorundesire d side-

effects

actual result expect result

registercondition code

memory

The “bootstrapping” Validation Fashion

Simplest functionComplete system

Incremental

The basic organization of BVT

Basic Function Test– Focus on each individual operation or

function are working properly– Also verify that unwanted side-effect do not

exist.» Example:

proper result is calculated register and memory are update correctly condition code are set properly.

The basic organization of BVT

Corner Case Test– boundary conditions cases of a function

» Example : underflow or overflow in floating point operation Cause address calculation to cross memory boundary

– exception cases of a function .» Example:

Proper prioritization of multiple exception

The basic organization of BVT

Sequence Tests – Multiple functions are executed sequentially

or concurrently– Sequences of multiple instructions interact

properly» Example :

Dependencies between instruction for register values,memory contents,and flag settings.

Applications

CPU-1750A– Inserted in an Air Force avionics system – provide 12 DAIS MIPS sustained at 60MHz

MS1– An x86-compatible micro processor– Developed in conjunction with Navy

BVT provides more test coverage than vector,application and/or random testing.

Conclusion

RTNI– Single cycle execution of COTS processor.– Standardized across multi-processor

including DSP– Visualize real-time data allows developers to

isolate where and why a particular real-time bug occurs.

Conclusion

BVT– Based on the systematic verification of the

specification– Significantly more effective in finding,

identifying, correcting, and re-testing bugs– Created to validate specifications for both

software and hardware