This document provides a functional specification for the New Kontron Emulator (NIKE). It describes the intended functions of the Development WorkBench (DWB) software, which provides an environment for software development, debugging, and emulation. The DWB is intended to operate various emulators and instruments to enable debugging of embedded software programs. It utilizes a graphical user interface with windows, menus, and mouse input. The document outlines the high-level software components and mechanisms needed to implement the DWB system.

1. I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
NIKE
Software Functional Specification
This document describes the
functional requirements for the New
Kontron Emulator (NIKE).
prepared by
Glen B. Alleman
and
Brad N. Yearwood
KONTRON ELECTRONICS
Irvine, California
17 Feburary 1984
Internal Review Release
software
Improved

2. I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Document Change History
Release
Review
Review
Review
Review
Review
Date
29.4.83
5.5.83
21.6.83
6.7.83
5.10.83
Description
Preliminary release for internal review.
Changed name of ISE to Development
WorkBench (DWB). The ISE is now the slave
instrument attached to the DWB.
Internal engineering review updates.
Technical writing review updates
Added link level protocol design
Added IEEE-488 specification
Added data base management specification
Author
GBA,
BNY
GBA
GBA
GBA
GBA

3. I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Table of Contents
o.o
1.0
1.1
1.2
1.3
2.0
3.0
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.S
3.1.6
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.3
3.3.1
3.3.2
3.3.3
3.3.4
BACKGROUND • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 0-1
INTRODUCTION • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 1-1
Product Environment ••••••••••••••••••••••••••••••••• 1-1
Market Forces •••••••••••••••••••...••.•••••••••••••• 1-2
Product Structure ••••••••••••••••••••••••••••••••••• 1-4
Basic Configuration ••••••••••••••••••••••••••••••• 1-5
Remote Host Configuration ••••••••••••••••••••••••• 1-6
Self Contained Configuration •••••••••••••••••••••••••• 1-6
ISE Product summary ••••••••••••••••••••••••••••••• 1-7
REFERENCE DOCUMENTS • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 2-1
FUNCTIONAL REQUIREMENTS DEFINITION •••••••••••••••••••• 3-1
What Does the DWB Do? • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Software Development ••••••••••••••••••••••••••••••
Program Development System CPDS) ••••••••••••••••
Language Translation ••••••••••••••••••••••••••••
Syntax Directed Editing •••••••••••••••••••••••••
software Debugging ••••••••••••••••••••••••••••••••
Execution Control •••••••••••••••••••••••••••••••
Execution Monitoring ••••••••••••••••••••••••••••
Information Display •••••••••••••••••••••••••••••
Assembly Language Debugging •••••••••••••••••••••
Process Level Debugging ••••••••••·····•••••••••••
Emulation •••.•••.•.•••••••••••.•••••••••••••••••••
Performance Analysis ••••••••••••••••••••••••••••••
State Analysis ••••••••••••••••••••••••••••••••••••
System Diagnostics ••••••••••••••••••••••••••••••••
How is the DWB Operated? ••••••••••••••••••••••••••••
Displayed Information •••••••••••••••••••••••••••••
Screen, Mouse and Commands ••••••••••••••••••••••
Window Manager ••••••••••••••••••••••••••••••••••
Window Examples •••••••••••••••••••••••••••••••••
Input Devices •••••••••••••••••••••••••••••••••••••
Command Language ••••••••••••••••••••••••••••••••••
Auxiliary Modes of Operation ••••••••••••••••••••••
How is the ISE Hardware Controlled? •••••••••••••••••
Emulator Personality ••••••••••••••••••••••••••••••
state Analysis ••••••••••••••••••••••••••••••••••••
state Analysis Instruments ••••••••••••••••••••••
Timer I Count Memory ••••••••••••••••••••••••••••
Timer I Count Memory Interface ••••••••••••••••••
Process Level Emulation Control •••••••••••••••••
Process Capture Sequencing ••••••••••••••••••••••
Control Mode Characteristics ••••••••••••••••••••
Mechanisms for the Context Release ••••••••••••••
Requirements for User OS Interface ••••••••••••••
Simulation Memory •••••••••••••••••••••••••••••••••
Slave Emulator Adaptor ••••••••••••••••••••••••••••
3-2
3-4
3-5
3-7
3-7
3-8
3-8
3-9
3-10
3-11
3-11
3-12
3-14
3-17
3-19
3-21
3-22
3-23
3-25
3-28
3-29
3-29
3-31
3-35
3-38
3-40
3-40
3-43
3-44
3-46

4. Table of Contents
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
3.4.6
3.4.7
3.4.8
3.4.9
3.4.10
3.5
3.5.1
3.5.2
3.5.3
3.5.4
3.5.5
3.6
3.6.1
3.6.2
3.6.3
4.0
How is the DWB Software Mechanized? •••••••••••••••••
Host Software Environment •••••••••••••••••••••••••
Slave Software Environment ••••••••••••••••••••••••
Display Manager •••••••••••••••••••••••••••••••••••
Cursor Control ••••••••••••••••••••••••••••••••••
Input Control and Processing ••••••••••••••••••••
Controlling the Window View •••••••••••••••••••••
Window Output •••••••••••••••••••••••••••••••••••
Active Window Data Flow •••••••••••••••••••••••••
Emulator Functions and Control ••••••••••••••••••••
Function Addressing •••••••••••••••••••••••••••••
Static RAM Control ••••••••••••••••••••••••••••••
Memory Mapping ••••••••••••••••••••••••••••••••••
Event Recognition •••••••••••••••••••••••••••••••
Target Probe Interface ••••••••••••••••••••••••••
Trace Monitor •••••••••••••••••••••••••••••••••••
Utility Processor •••••••••••••••••••••••••••••••
Serial Interface ••••••••••••••••••••••••••••••••
External Event Module •••••••••••••••••••••••••••
Target Probe Module •••••••••••••••••••••••••••••
Auxiliary Instrument Control ••••••••••••••••••••••
Terminal and Screen Interface •••••••••••••••••••••
Command Language Processor ••••••••••••••••••••••••
Literals ••••••••••••••••••••••••••••••••••••••••
Variables •.•..••....•......•.•.•..•.•...•••.•••.
Messages ••••••••••••••••••••••••••••••••••••••••
Command Language Syntax•••••••••••••••••••••••••
Interpretive Mode •••••••••••••••••••••••••••••••
Internal Compilation ••••••••••••••••••••••••••••
Intrinsict Procedures •••••••••••••••••••••••••••
Debugger Control • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Logic Analyzer Control ••••••••••••••••••••••••••••
Structure Editor ••••••••••••••••••••••••••••••••••
What are the Requirements for Mechanization? ••••••••
Hardware Environment ••••••••••••••••••••••••••••••
Operating System Environment ••••••••••••••••••••••
Interprocess Communication ••••••••••••••••••••••
Event Management ••••••••••••••••••••••••••••••••
Process Management ••••••••••••••••••••••••••••••
File Management •••••••••••••••••••••••••••••••••
Virtual Operating System summary ••••••••••••••••
Communication Protocol Environment ••••••••••••••••
Nature and Purpose of the Reference Model •••••••
Port Architecture Model •••••••••••••••••••••••••
Transport Protocol Facilities •••••••••••••••••••
Portability Considerations ••••••••••••••••••••••••
Data Base Manager •••••••••••••••••••••••••••••••••
DWB Software Development Environment ••••••••••••••••
Programming Language Requirements •••••••••••••••••
Development Configuration Control •••••••••••••••••
Quality Assurance and Testing •••••••••••••••••••••
Product Life Cycle ••••••••••••••••••••••••••••••••••••
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

5. I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
Table of Contents
s.o Alternative Approaches & Tradeoffs ••••••••••••••••••••
5.1 Low Cost ISE (!SE Cube) •••••••••••••••••••••••••••••
6.0 Possible Future Enhancements • • • • • • • • • • • • • • • • • • • • • • • • • •

6. I NIKE Functional Specification
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
o.o BACKGROUND
The pace of the current microelectronic revolution is
unparalleled; it outstrips the pace of the development of the
mainframe computer itself. In little more than a decade,
microprocessors have evolved from the Intel 4004, a four-bit
machine, to 32-bit chips. In the case of mainframe computers,
the "maturity" of a 32-bit word length came with the IBM 360
series, two decades after the introduction of the first
computers.
The semiconductor industry continues to invest heavily in the
development of complex microprocessors whose performance
characteristics now rival the popular minicomputers. While
development takes place on the 32-bit architecture, the 16, 8,
and 4-bit machines are moving to the next generation in terms
of speed, size, and power consumption. In addition, the
predicted decline in the 8-bit market has not taken place;
instead the production volume of existing products is
increasing, with new 8-bit products being announced by Zilog
and Intel.
Within this rapidly expanding microcomputer market, the demand
for slave emulation is both increasing and decreasing, and in
some cases being eliminated. In the 32-bit market, the chips
themselves provide many of the features needed for debugging
software systems. On-board diagnostics, machine level
debuggers, and high-level language architectures create an
environment hostile to the slave emulator. Significant
increases in processor clock speed are appearing in the 16-bit
market, with 20MHz MC68000s proposed in the near future. The
slave emulator must operate in a transparent mode with target
system bus speeds of SM-transfers/second. Self-contained
microcomputers are leading the way in the 8 and 4-bit market.
These machines contain the necessary logic to produce a single
chip computer, cutting off the slave emulator from the control
signals necessary to capture and manage the execution of the
target processor.
This market presents a confusing set of requirements for the
next generation of emulators and logic analyzers. It is for
this market place that NIKE must be designed. The design
challenge is approached from several fronts, each building on
past products. An important change is introduced though; the
software development environment is now a driving factor for
the next generation of KONTRON products.
section o.o Page 0-1

7. I NIKE Functional Specification
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1.0
1.1
TARGET MARKET PLACE
This document describes the software functional requirements
for NIKE. The product resulting from this specification will
meet the needs of a specific market place.
Our concept of this market is:
The embedded real-time control environment in which a
microprocessor directly controls a fucntion through
tightly coupled peripherals. Typically no keyboard, CRT,
or mass storage device is connected to the target system.
This environment is most often found in process-control
systems, avionics computers, video games, communcations
systems, and single board computers.
Product Environment
The market demands of the 32-bit/virtual memory based emulator
product (The Imporved Slave Emulator ISE) are uncertain at
best. The software system described in this document defines an
intermediate product that is both producable in a short period
and meets the perceived demands of the current 16-bit and 8-bit
emulator market.
To acheive the goal of producing an emulator in a short time
span (12 months), the ISE system design will be "defeatured".
Two major areas will be reduced in scope from the features
described in the ISE Software Specification of 6 JUNE 1983.
These features are:
o The operator interface will be reduced from an
intercative multi-window, mouse driven system to one
based on a "dumb terminal" interface. This interface
will still make use of windowing, but more in line
with the facilities currently provided by the KDS.
o The hardware/software configurations available in the
proposed ISE product will be reduced to a single
configuration. The Slave Emulator hardware will be a
self-contained unit connected to one of three
possible hosts:
- A Kontron KDS-9068 UNIX host
- A DIGITAL VAX or PDP-11 host
- An IBM-XT running a multitasking operating
system (MS-DOS 3.0, UNIX, or XENIX).
Section 1.0 Page 1-1

8. NIKE Functional Specification
The target market for the NIKE product is limited to the 8-bit
and 16-bit microprocessors. These target processors are those
that Kontron currently supplies (or propoese to supply)
emulators for:
- MC68000 and its derivatives
- INTEL 8086/87/88, 186/188
- Z80/Z800
- Fairchild 9445
During the design of a microprocessor based system, the
hardware/software integration phase presents the most difficult
task for the implementors. This phase of the development cycle
generates design changes that must be implemented quickly to
maintain maximum productivity. Prior to the integration phase
software development must proceed with a prototype hardware
system, while hardware development must proceed with a
prototype software system. In the system integration phase all
parts of the microprocessor system are brought together for the
first time. Integration is a process of refinement and change
which may be further complicated by the use of multiple
processors, high level languages, and heterogenous hardware.
The development tools used by the hardware and software
designers in the integration phase (as well as in other
phases), must offer flexibility, power, and ease of use.
Typical microcomputer system projects range from a single-
person task to a large-scale hardware and software development
effort. The NIKE provides a comprehensive set of tools to deal
with a variety of work environments including facilities for
timing analysis, state and logic analysis, software performance
measurement, high-level language debugging, and software
engineering tools. The NIKE provides the foundation for for
this environemnt through an integrated set of hardware and
software development tools.
It is this integrated capability that sets the NIKE and its
Improved Slave Emulator apart from a traditional incircuit
emulator. To meet the requirements of the next generation
procuct development environment we propose the construction of
a new generation of hardware and software tools.
Section 1.0 Page 1-2
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

9. I NIKE Functional Specification
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1.2 Market Forces
Undertaking a major development project requires careful
thought and planning. The first question asked must be why are
we doing this? Several forces are pushing the development of
an Improved Slave Emulator instrument controlled by the DWS:
o The current slave emulator architecture is not capable of
dealing with the high-speed processors appearing on the
market. Machines with system clock speeds of 15 to 20 MHz
will be available in the next 12 months. The current slave
hardware is only capable of emulating 10 MHz processors.
The bus architecture of the ADS/KDS slave (which supports
2Mwords/sec transfer rates) will not support execution
speeds above lOMHz, these limitations require a new bus to
be designed.
o The current slave emulator hardware supports a 26-bit
physical address space and a 16-bit data transfer width.
Several 16-bit processors support 32-bit real addresses,
with multiple address spaces. This limitation requires a
new bus to be designed.
o The trends in microcomputer software development are
toward High-Level Language (HLL) based systems. The
ADS/KDS software debugger provides no facilities for
supporting software development beyond an assembly
language debugger. The hardware architecture of the
current Slave is not capable of providing the address and
data range breakpoint facilities needed for a HLL
debugger. This limitation forces a new design effort.
The Improved Slave Emulator CISE) instrument attached to the
Development Workbench is characterized by the following
performance features:
o Dual bus architecture - high speed data bus and medium
speed control bus
o Up to 20MHz system clock rates
o Up to 5Mwords/second bus transfer rates
o 24-bit logical and physical address space
o 16 address spaces resulting in a 28-bit address space
o Improved Real-time transparency
o Tagged memory architecture to support HLL debugging
Section 1.0 Page 1-3

10. NIKE Functional Specification
Features that set the NIKE apart from the current products are
extensions, enhancements, and architectural changes designed to
meet the expanding market requirements for tightly coupled
Software Development and Emulation. These features include:
o Performance Monitoring: The NIKE provides performance
monitoring facilities that create histograms of execution
times, memory access sequences, event timings, and system
resource utilization.
o Tagged Simulation Memory: The NIKE provides memory tags on
byte boundaries to support the Debugger and Performance
Monitor.
o High Level Language Debugging: The NIKE provides
facilities to develop and debug target system software in
Pascal and c. These facilities go beyond the debugging
tools available in our current product. Objects within the
target language are manipulated and controlled · through
the debugger. Procedures, files, variables, records,
arrays, and , code segments are addressable by name.
Breakpoints can be placed on language statements, variable
names, and procedure calls. Resource utilization
histograms, memory access analysis, and complex breakpoint
conditions are features of the high level language
debugger.
Section 1.0 Page 1-4
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

11. I NIKE Functional Specification
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1.3 Product Structure
Before proceeding with the functional description of the NIKE,
the product structure of the system will be described. The NIKE
is fundamentally different from the current generation of
KONTRON emulators; in that the emulator is a true slave to the
host processor. The emulator hardware responds to commands
generated by the host and returns information only when
commanded to do so.
The Development Workbench consists
hardware and software components.
with the other through a set
architecture of NIKE can best
cooperating hardware and software
of a tightly coupled set of
Each component communicates
of layered protocols. The
be described as a set of
modules.
***************** NOTE ******************
The software components which make up the
NIKE come from several sources: from
third party vendors, from in-house
development, and from customers.
The Development workbench is organized in a layered set of
software and hardware:
User Interface
Level
Application
Level
Operating
System
Level
Facility
Controllers
Physical
Device
Controllers
Instruments,
Devices
+----------------------------------------------+
Man I Machine Interface
+----------+-------------+------------+--------+I HLL I Performance I • • • • • I • • • • I
I Debugger I Analyzer I I I
+----------+-------------+------------+--------+
Operating System Interface
+------------+------------+--------------------+I Debug I Emulator I • • • • • • • • •
I Controller I Controller I
+------------+------------+--------------------+
Instrument Controller Communication System
+-----------+-----------------+~---------+-----+
Improved
Slave
Emulator
I • • • I
I I
I I
+-----------+-----------------+----------+-----+
Section 1.0 Page 1-5

12. NIKE Functional Specification
The Development Workbench consists of three major software
components:
o Emulator Control software residing in EEPROM that manages
the low level functions of the slave emulator instrument.
This component is a distributed system with software
residing on the host and in the slave instrument's onboard
processors.
o Human Interface software that controls the display and
input devices that are available to the user. This
component manages the interaction between the application
level software and the lower level control software.
o Application Control software that manages the action of
the various instruments attached to the host processor.
This component implements the data processing features of
the Development workbench.
The NIKE hardware comes in one configuration:
Basic Configuration
The basic configuration is composed of a local host and a
tightly coupled Improved Slave Emulator (ISE) Instrument. The
connection between the host and the slave is provided by the
IEEE 488 bus. The local host is a 16-bit processor, preferably
one manufactured by KONTRON, which is executing a multi-tasking
operating system. Control of the Slave Emulator is initiated
from the host through a message protocol. The slave executes
the commands contained in the messages, and returns the results
to the host. No interaction takes place between the Slave and
the Host unless it is solicited by the Host. The Slave Emulator
hardware consists of the following major components:
o A Cycle Trace Analyzer board with built-in trace memory
o An Event Detector and Sequencer (Break Point) board
o An probe Interface Module and a Probe that controls the
target system probe
o An External Event board that connects triggers to the ISE
from external devices
+-----------+ +----------+User Display-->! HOST I Communication! Slave I
Keyboard------>! MC68000 +--------------+ I
Mass storage-->! (typical) Channel Emulator I
+-----------+ +----------+
Section 1.0 Page 1-6
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I

13. I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
NIKE Functional Specification
DWB Product summary
o Software Development I Debugging
- High Level Language debugger (PASCAL)
- Symbolic debugging for assembly language
- Incremental assembler
- Performance analysis
o Emulation with ISE Support
- Complex breakpoint control
- Tagged memroy architecture
- Trace analyzer
- External event control and generation
o System Features
- Built in diagnostics
- Software is portable to multiple host environments
- Slave Emulator can connect to Non-KONTRON hosts
- Multiple emulation support
Section 1.0 Page 1-7

14. I Development WorkBench Specififcation
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
2.0 REFERENCE DOCUMENTS
The following documents serve as reference for the ISE software
functional specification. Since the ISE is a new product
development, it is important to lay a proper foundation for the
understanding of the concepts behind the ISE. This is the
primary purpose of the reference documents.
o nA Performance Comparison of Three Contemporary 16-Bit
Microprocessors,n M. De Prycker, IEEE Micro, April 1983,
pp 26-37.
This article describes the underlying theory behind
measuring the performance of 16-bit microprocessors. It
also establishes requirements for high-level language
performance monitoring and debugging.
o nTransport Protocols: Their Performance and Status in
International Standardization (July 1982),n P. von
Studnitz, Computer Networks, Volume 7, Number 1, pp 27-36.
This article describes the basis of Transport
and their place in distributed architecture
design.
Protocols
systems
o nsoftware Development System,n B.R. Rowland and R. J.
Welsch, The Bell System Technical Journal, January 1983,
Volume 62, Number 1, Part 2, pp. 275-290.
This article describes the development environment for the
3B20 processor and the DMERT operating system. The
concepts presented here are applicable to the software
development needs of the ISE engineering workstation.
o Pascal-2 User Manual, Version 2.0 for UNIX, Oregon
Software, 2340· s.W. Canyon Road, Portland Oregon 92701.
This manual describes the software debugger for Pascal-2.
It serves as a model for some of the debugging features of
the ISE.
o •visiCorp's Windows on the worldn, R. Folk, PC world,
March 1983, Volume 1, Number 2, pp. 40-55.
This article describes the
Vision product. The window
incorporated into the
requirements.
current version of VisiCorp's
management scheme of Vision is
ISE man/machine interface
Section 2.0 Page 2-1

15. Development workBench Specififcation
o "Physical Level Protocols,•
Transactions on Communications,
April 1980.
H. v. Bertine, IEEE
Volume COM-28, Number 4,
"Character-Oriented Data Link Control Protocols,• J. w.
Conard, IEEE Transactions on Communications, Volume COM-
28, Number 4, April 1980.
"Bit-Oriented Data Link Control Procedures," D. E.
Carlson, IEEE Transactions on Communications, Volume COM-
28, Number 4, April 1980.
"Multiaccess Protocols in Packet Communication systems,"
F. A. Tobagi, IEEE Transactions on Communications, Volume
COM-28, Number 4, April 1980.
These papers serve as the basis for ALL communications
systems design. The models presented here are used to
control the design of the layered transport protocol of
the ISE.
o VRTX/86 User's Guide, Hunter & Ready, 445 Sherman Avenue,
Palo Alto, CA 94306.
This manual describes the "silicon software" operating
system for the iAPX-188 processor which resides on the
individual !SE boards.
o "4.2BSD System Manual", w. Jay, et al, UC Berkely,
Department of Electrical Engineering and Computer Science,
Draft of September 1, 1982.
This manual describes the BSD 4.2 UNIX system.
o IEEE Recommended Practice for Code and Format Conventions,
IEEE Std 728-1982, IEEE 345 East 47th Street, New York, NY
10017.
This manual describes the IEEE-488 GPIB codes and formats
that are to be generated, processed, and interpreted by
the device controllers of the instruments connected to the
bus.
o iAPX-188 High Integration 16-Bit Microprocessor, Intel
210451-002, Preliminary Release, 1982.
section 2.0
This manual describes the operation of the Intel 80188
microprocessor.
Page 2-2
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
I
1.
I
I