Skip to main content

Full text of "HP Journal 1985-09"

See other formats


© Copr. 1949-1998 Hewlett-Packard Co. 



September 1985 Volume 36 • Number 9 


4 VLSI Delivers Low-Cost, Compact HP 3000 Computer System, by James H. Holland 
Frank E. La Fetra, Jr. The key to success was lull family membership, including operating 
system and object code compatibility with larger HP 3000s. 

High-Volume Test Strategy 


Simplicity in a Microcoded Computer Architecture, by Frederic C. Amerson Simplic- 
ity means more efficient use of silicon without sacrificing performance. 

Using a Translator for Creating Readable Microcode 
12 Booting 64-Bit WCS Words from a 32-Bit-Wide ROM Word 


Simulation Ensures Working First-Pass VLSI Computer System, by Patria G. Alvarez, 
Greg L Gilliom, John Ft. Obermeyer, Paul L. Rogers, and Malcolm E. Woodward 

A simulator with the improbable name "Faster Than Light" was the essential tool. 

1 Creative Ways to Obtain Computer System Debug Tools, by William M. Parrish, Eric 
B. Decker, and Edwin G. Wong The ways include an off-the-shelf microcomputer and a 
virtual software debugging panel. 

20 The Role of a Programmable Breakpoint Board 
22 Virtual Microcode Memory 

Q r New Cardiograph Family with ECG Analysis Capability, by Robert H. Banta, Jr., Peter 
<_0 H. Dorward, and Steven A. Scampini These instruments can reduce a physician's 
work load by providing a preliminary analysis of heart behavior. 

24 ECG Storage and Transmission 
27 Artifact Generation 


Computer-Ai Jed ECG Analysis, by John C. Doue and Anthony G. Vallance Special 
signal processing and algorithms are required to detect various ECG abnormalities 

30 ECG Criteria Language 
Pediatric Criteria 



Edilcx. Richard P Man • Associate Editor KennethA Stiavv m Assistant Editor NancvR Teater • Art Director. Photographer ArvidA Danielson • Support Supervisor SusanE Wnghl 
Illustrator Nancy S VanderOioom • Administrative Services. Typography. Anne S LoPresl> • European Production Supervisor Michael Zandwi|ken • Publisher. Russell M H Berg 


C> Hewletl-Packa/d Company 1985 Printed mUSA 

© Copr. 1949-1998 Hewlett-Packard Co. 

Our cover subject this month is the HP 3000 Series 37 Computer This 
newest and smallest member of Hewlett-Packard s business data processing 
computer family is an affordable, user-installable system that supports up 
to 28 terminals and is suitable for small companies (like the horse breeder 
suggested by our cover photo) or for departments or workgroups of larger 
companies. At about half the price of the previous entry-level HP 3000. the 
Series 37 makes this computer family accessible to many more users. A 
major advantage is that all HP 3000 Computers run the same software. HP 
offers standard upgrades to larger systems from any family member, so a 
user starting with the Series 37 has an easy growth path all the way to a system that supports 
as many as 400 terminals and can handle the data processing needs of a fairly large company, 
and no reprogramming or software conversion will be required at any step. Any HP 3000 can 
also be part of a network that includes other HP 3000s. mainframe computers, personal computers, 
and engineering workstations. For example, HP's own worldwide electronic mail system runs on 
a network of HP 3000 Computers. 

The Series 37's designers report on its design on pages 4 to 22. Among the engineering 
challenges was the integration of the central processing unit (CPU) on a single semicustom gate 
array chip (page 7). Simulation of the CPU chip and another gate array (page 13) refined the two 
chip designs to the point where the first chips produced worked as designed, a major accomplish- 
ment. To keep the cost low and ensure reliability and family compatibility, the project was carefully 
managed (page 4). and the hardware and software debugging tools received special attention 
(page 17). 

In the articles on pages 25 to 36. you'll find the design story of the new HP 4760 PageWriter 
Cardiograph family. While a cardiograph is very different from a business computer, the major 
engineering contribution in the HP 4760 family is much like the Series 37's— very large-scale 
integration puts more computing power into a smaller package. Two of the new cardiographs 
have parts of the HP ECG analysis program, formerly available only in a separate computer 
system, built right in, along with a dedicated 68000 microprocessor. The HP 4760AM, which has 
the ECG measurements portion of the program, can make more than 4000 measurements on 
the ECG waveform and print the complete results or a summary. The HP 4760AI has the full 
ECG analysis program and provides an interpretation of the ECG waveform. Adult analysis is 
standard; pediatric analysis, based on age-dependent criteria, is an option. Some feel that such 
automated interpretation can be helpful in eliminating normals in high-volume screening, or in 
emergencies when no cardiologist is available. The ECG measurements capability helps the 
cardiologist reduce interpretation time and is useful in research and teaching. 

R. P. Dolan 

What's Ahead 

Next month's issue will be devoted to the design of the HP Integral Personal Computer. The 
HP-UX operating system of this 25-pound transportable computer is HP's version of AT&T Bell 
Laboratories' UNIX '"operating system. 

© Copr. 1949-1998 Hewlett-Packard Co. 


VLSI Delivers Low-Cost, Compact HP 3000 
Computer System 

This entry-level, user-installable computer system runs the 
same software as the largest HP 3000, but fits under a table 
and is much quieter than a typewriter. 

by James H. Holl and Frank E. La Fetra, Jr. 

THE HP 3000 COMPUTER product line is HP's cur- 
rent-general ion business computer family. At the top 
of the line is the HP 3000 Series 68, which is capable 
of supporting hundreds of terminals and handling the data 
processing needs of a fairly large company. The newest 
and smallest HP 3000 is the Series 37, Fig. 1. a compact, 
quiet office computer capable of supporting up to 28 users. 
Like all HP 3000s, the Series 37 runs the same software as 
the Series 68. Although slower than the Series 68, of course, 
the Series 37 has about the same processing power as the 
Series III. the top-of-the-line HP 3000 when it was intro- 
duced seven years ago. VLSI (very large-scale integration! 
is the key to the exceptional price/performance of the new 

The HP 3000 Series 37 was conceived as the answer to 
the need to add a low-cost computer to the HP 3000 product 
line while maintaining reasonable performance. Although 
the need was obvious (many people are willing to take 

credit for discovering it), the solution remained elusive 
until a key project manager proposed a product that evolved 
into the Series 37. 

Design Objectives 

The original design objectives stated at (he time the proj- 
ect was proposed were: 
I Low system list price 
■ Four to eight terminal ports 

n Mean lime between failures (MTBF) greater than 2 years, 
including peripherals required to run the operating system 
Mid-1983 manufacturing release 

I ' Series III performance 

c Easier to use — you turn it on and it works 
Networking capability. 

Most of the original objectives were met. The system list 
price is in the originally targeted range. Seven terminal 
ports are standard; 28 is the maximum number. The esti- 

Fig. 1. The HP 3000 Series 37 
Computer runs the same software 
as other HP 3000s. supports up 
to 28 terminals, and fits easily into 
an office environment. The Series 
37 system processing unit is the 
second unit from the top in the 
cabinet at right. 


© Copr. 1949-1998 Hewlett-Packard Co. 

mated MTBF of the system processing unit is 1.17 years, 
which did not meet the goal. However, the two-year goal 
was very aggressive and involved many separate parts of 
our corporation. The time to market goal was based on the 
time it would take to complete similar projects, on the 
average. This is called our 50% schedule because it is ex- 
pected that the schedule can be met half of the time. The 
time it would take to complete nine out of ten similar 
projects was also projected, and this 90% schedule estimate 
turned out to be exactly the time taken. The actual release 
date was February 1985. 

The Series 37 has Series III performance with up to 20 
terminals. It can be installed by the customer without ex- 
pert assistance and is ready to run applications when it is 
first turned on. The Intelligent Network Processor is part 
of the initial release, so the networking goal was met. 

Our lab teams operate in an environment that allows 
them to set their own, often aggressive goals, which they 
strive toward but do not always achieve. This encourages 
our teams to take appropriate risks in areas where there is 
a range of acceptable results. Performance is an area where 
risk is appropriate. Product quality is an area without much 
opportunity for risk taking. Although this project did not 
meet all of its goals, it is considered to have been successful, 
since the product met the goals considered important by 
both management and the project team and has sold well, 

Initial Design Approach 

The originator's first designs emphasized maximum 
hardware integration. The team considered a single printed 
circuit board with everything on it. including the control- 
lers for the peripherals. This design would contain no con- 
nectors and assembly would consist of snapping things to- 
gether. This approach would minimize cost at the expense 
of configuration flexibility. The team chose to add the ability 
to expand memory and thus avoided being trapped with a 
small memory while memory use continued to expand. 

The single printed circuit board with everything on it 
might have been fully explored had not organizational con- 
siderations within HP brought about its early termination. 
HP entities have traditionally produced both hardware and 
the software necessary to make it function. They tend to 
use revenues from hardware sales to support the software. 
Although this trend was changing when the Series 37 proj- 
ect began, there was enough concern to justify separating 
the hardware along divisional boundaries. The team de- 
cided not to produce a new version of the peripheral con- 
trollers and made the I/O channels separate printed circuit 

Another early decision led to the inclusion of operating 
instructions in the product packaging. This evolved into a 
pull-out card with instructions on it. The card became un- 
popular when we faced the issues involved in localizing 
the card for the other languages we support. The card was 
eliminated late in the project when it was noted that its 
slot was contributing significantly to electrical noise radiat- 
ing from the system. 

Active Investigation 

The team made attempts to eliminate costly features that 
had become standard on members of the HP 3000 family. 

These efforts had some success. A batten- to sustain the 
memory during powerfail is an example cf a feature that 
was eventually retained. A separate service processor is an 
example of a feature that was deleted. The Series 37 achieves 
its maintenance functions by putting itself into a different 
mode of operation (see article, page 17) The system acts 
as its own service processor. Although there isn't a separate 
sen-ice processor in the Series 37. many features needed 
to debug system software problems have been made avail- 
able by a microcoded debug package. 

"Keep it simple" became a motto for the team. This led 
to the decision not to support peripherals that could not 
share their channels. Since we were channel limited, we 
couldn't afford to dedicate a channel and didn't want the 
coordination problems involved in working with other HP 
divisions to redesign their products. Another decision was 
to refuse the offer of another division to take control of our 
terminal connections. Thus, we avoided the management 
complexity that would have resulted had we increased our 
dependence on HP entities outside the project's control. 

Although we wanted to use the newest subsystems being 
developed within HP. we didn't want to introduce any part 
availability problems. We discovered that unless new prod- 
ucts were produced with the HP 3000 family in mind, they 
invariably lacked features required of an HP 3000 system 
component. Powerfail/auto-restart functionality is a good 
example of a frequently missing capability. 

We are finding that we can develop new hardware faster 
than the software required to make it function. Because 
our software resources were committed to other projects, 
many early decisions were made to minimize the impact 
on the software development teams. In many cases, emerg- 
ing products looked very attractive until we realized that 
the software for them couldn't be developed in time. This 
situation, together with the other problems we found trying 
to use emerging products, led us to decide to leverage the 
huge investment in existing I/O software lor HP-IB (IEEE 488) 
and ATP (Advanced Terminal Processor) peripherals instead 
of using peripherals that required software development. 

Development of new system microcode has been a historic 
bottleneck. To reuse an existing (and working) microcode 
set. we attempted to copy an existing hardware design, hut 
couldn't find any that were suitable for VLSI. We eventually 
built a microcode development team and wrote totally new 

Development Phase 

Our VLSI processor was put into a single gate array to 
avoid the performance and connection limitations of a par- 
titioned design. We selected the gate array by looking for the 
largest gate array that was already in production and would 
require little power (see article, page 7|. We also put part 
of the terminal interface controller into VLSI. 

Full simulation was correctly seen as necessary to get 
the VLSI designs right before they were fabricated (see article, 
page 13). Much of this work was performed on the most 
powerful systems available to the design team. Simulation 
was also used to debug microcode before the hardware was 
available. We ran the initial part of the system boot software 
on a simulator. The limiting factor became the effort it took 
to give the simulator the I/O information that the software 


© Copr. 1949-1998 Hewlett-Packard Co. 

High-Volume Test Strategy 

At the beginning of the design phase tor the HP 3000 Series 
37 Computer, it was dear to Ihe manufacturing team that (he 
produclion methods used on the existing HP 3000 production 
line would require a compiete revamping if manufacturing were 
to be successful in meeting the high volume demands projected 
The key was clearly in developing a lesl strategy that allowed 
high throughput, high confidence of shipping 100% operational 
systems, and efficieni diagnostic tools, none of which could be 
at the expense of lengthy test times. This meant more than just 
a new set of diagnostics and lesl tools. 

The R&D team felt confident that Ihe design tools used, coupled 
with the dramatic parts count reduction, would make this HP 
3000 one of the most reliable But they agreed that the need for 
manufacturing to be able to build 100% quality systems in high 
volume had to be addressed Thus the HP 3000 Series 37 be- 
came a springboard to launch the Computer Systems Division 
into a completely new methodology for manufacturing complex 
computer systems. Relative to the test strategy, manufacturing 
engineering felt the major goals were to: 

■ Establish a new, more effective real-time method of feedback 
to the lab on the product and product testing 

■ Establish a test flow that no longer requires highly technical 

■ Develop a process that emphasizes good inventory, not test- 
and-reject-to-be-fixed inventory 

Feedback to the lab was established in an unusual way The 
manufacturing team was established before the laboratory pro- 
totype phase Technicians and production engineers worked with 
the R&D lab during this phase to gain familiarity with the tools 
and the product All remaining product phases were performed 
at the manufacturing site by the manufacturing team with techni- 
cal support from the lab Thus the lab team received feedback 
on the strategy and hardware before concepts were too de- 
veloped to change Manufacturing provided weekly summaries 
of all problems and concerns to the lab for review This was 
successful even though the lab and manufacturing were sepa- 

rated by over 150 miles 

The R&D team put great effort into realizing the key diagnostic 
tests as power-on self-tests (microdiagnostics). which clearly 
indicate to the operator whether the system is operational Scripts 
that detailed step-by-step system verification procedures were 
established by production engineering early in the cycle. These 
were later augmented with a Diagnostic Utility System, which 
allows the streaming of tests, thus virtually eliminating operator 

The Series 37 established a new concept in testing HP 3000 
Computer Systems. Production personnel receive completed 
mainframes in the System Verify area (see Fig 1) and attach 
typical peripherals to execute microcoded self-tests and other 
higher-level tests. The operator is required to ensure that each 
system completes this testing phase without error If an error 
occurs, the failure mode is noted and the unit is rejected No 
problem isolation methods are allowed. This lets the operator 
focus on the system's operation and not merely on getting a 
system ready to ship by swapping in olher material. The defective 
units are sent to the Defect Analysis stations. These are equipped 
with all the hardware debug tools and are operated by highly 
trained technicians, who determine the cause of the defect Be- 
cause the entire system is available, these stations are able to 
locate most of the otherwise elusive failures that occur when 
hardware is swapped between systems. The causes of defects 
are reviewed weekly so methods can be established to eliminate 
the defects from the process The goal is to eliminate all defects, 
so that none are found m the System Verify area. 


Laurie Schoenbaum implemented the memory test used in 

Dennis Bowers 
Manufacturing Engineer 
Computer Systems Division 

- ■ 



A = 

B = 

G = 

C = Cabinet 

R = Racks and Carts 

W = Custom Work Bench 

FR = Flow Racks 

DA = Defect Analysis 

SYS VRFY = System Verity (Test) 

Fig. 1. HP 3000 Series 37 build-tesl production line. 

needed to continue to run. 

The final key to success was full family membership. 
We had to make the Series 37 a real HP 3000 in the eyes 
of the users. Fortunately, we were shooting at a fairly sta- 
tionary target and were able to achieve this goal. As a result, 
the HP 3000 software team decided to include the Series 
37 in their effort to consolidate operating systems into one 
version. All of HP's currently manufactured HP 3000 sys- 

tems can run the same version of MPE (Multiprogramming 
Executive, the HP 3000 operating system). 

The Series 37 had already completed a number of suc- 
cessful production runs in our manufacturing area before 
the project was completed. This allowed us to ship a large 
number of systems as soon as the system was released, and 
gave us a chance to stress a large number of systems en- 
vironmentally before release. Systems were subjected to 


© Copr. 1949-1998 Hewlett-Packard Co. 

high and low temperatures, high humidity, and a packaged 
drop test. We used the information gained by our stress 
testing to improve the systems before shipments began. 

Conclusion and Summary 

The Series 37 is an incremental member of the HP 3000 
family It runs the newest version of the MPE operating 
system, provides powerfail/auto-restart capability and al- 
lows remote support. It is the smallest and lowest-priced 
HP 3000 there has ever been. 

The Series 37 reduces the need for operator control to 
the point where an operatorless environment is achievable 
for some customers. It is the most reliable HP 3000 system 
ever produced and is suitable for the office environment. 

The time to start a system from cartridge tape has been 
greatly reduced from that of older versions of MPE. This 
is because of the ability to stream the tape during the boot 
process. The Series 37 contains a real-time clock that con- 
tinues to run when the system power is removed. This 
clock allows the boot process to set the time of day without 

operator input. 


The Series 37 is the result of Rick Amerson s ideas and 
a lot of hard work. Peter Rosenbladt led the first half of 
the project and one of the authors and Alan Christensen 
led the second half. Rick"s team developed the VLSI portion 
of the CPU and the memory. The rest of the hardware was 
proposed by Mark Linsky's group. Barry Bronson replaced 
Mark after the investigation was complete. The author's 
group developed the system microcode and the service 
tools, Greg Gilliom led the microcode team during the last 
half of the project. The other author led the serviceability 
group after it was separated from the microcode team. The 
industrial design was done by three teams: Manny Kohli"s 
team worked on the initial design. Gerry Gassman's team 
took over from them, and Frank Sindelar's team took care 
of the final set of challenges. The software team was led 
by Kathy Hahn. Kathy and system manager Hank Cureton 
led the effort to release the system. 

Simplicity in a Microcoded Computer 

by Frederic C. Amerson 

A SIMPLIFIED APPROACH to the design of a micro- 
coded architecture can produce a design that is 
more efficient in its use of silicon than one bused 
on specialized hardware functional units, without sacrific- 
ing performance. The HP 3000 Computer, first introduced 
in 1972, has had a number of different implementations 
using various degrees of specialized hardware. The most 
recent of these, the Series 37, is the first HP 3000 CPU lo 
be implemented in VLSI technology. This article describes 
the design approach used to implement the CPU chip and 
the efficiencies achieved. From the initial concept of the 
design to the final working production parts was less than 
one year. 

There are two principal types of computer architecture 
in widespread use today: stack architecture and register 
architecture. Stack architecture is so named because the 
computation is done on a data stack. Numbers are moved 
to this stack from memory, an operation is performed leav- 
ing the result on the stack, and then the result is stored at 
some (other) location in memory. Register architecture per- 
forms computations in general-purpose registers. Numbers 
are first moved to one or more registers, an operation is 
performed leaving the result in a specified register, and 
the numbers are stored at some (other) location in memory. 
Some stack and register machine implementations allow 
operations that use memory operands directly without first 


■■^■•iwnr?rw,.rtrrmtr^.r ri +<.ar,t--- . : • 

Fig. 1. The Series 37 CPU chip is a CMOS gale array using 
nearly 8000 gates 

© Copr. 1949-1998 Hewlett-Packard Co. 


moving them to the stack or registers. 

The HP 3000 is a stack machine that has a very rich 
instruction set, which has been enhanced over the years 
and has grown to provide the user with a robust capability 
for data processing in commercial applications. Although 
many of its operations are performed directly on the stack, 
it is possible to perform some operations using stack 
operands with memory operands, and others (e.g., COBOL 
instructions and extended-precision floating-point instruc- 
tions) using memory operands only. Instructions that pro- 
cess only data on the stack are called stackops. In the HP 
3000, two of these instructions can be contained in the 
same space that a single instruction would normally oc- 
cupy and are referred to as paired stackops. This makes 
for more efficient use of code space in the event that two 
stackops occur in succession. Another very powerful group 
of instructions is the memory reference instructions. These 
instructions access a memory operand directly. In some 
cases it is merely loaded onto or stored from the stack, but 
in others, computation is performed using the memory 
operand. There are several addressing modes available for 
the memory reference instructions, allowing data to be ac- 
cessed relative to any of several different base registers. A 
scheme of encoding these, referred to as Huffman encoding, 
enables this important information to be encoded in fewer 

Series 37 Design Methodology 

Putting a processor onto a single chip is an extensive 
effort that requires thoroughness and careful attention to 
detail. The Series 37 presented a particularly difficult chal- 
lenge because of the powerful HP 3000 instruction set and 
the flexibility it provides. There exist several predecessors 
that might have been used as models, but none of these 
had been implemented on a single chip. The processor 
offering the closest comparison is the Series 48. which is 
contained on two boards. Its extensive use of high-density 
memory parts precludes its implementation in a single- 
chip CMOS design. The designers of the Series 37, there- 
fore, created a new design, structured specifically for the 

VLSI technology available. 

The Series 37 uses gate-array technology (see photo. Fig. 
1), so there is an absolute upper bound to the amount of logic 
that can be contained in the chip, making it imperative to 
conserve chip space while optimizing performance. The de- 
sign approach had to be as simple as possible yet elegant 
enough to achieve performance goals. Special hardware assists 
were kept to a minimum, with preference given to simplicity 
and ease of design rather than maximum performance. 

It was decided to eliminate interdependencies between 
portions of the design as much as possible. This approach 
gives rise to a multiplicity of independent functional units, 
each capable of performing one small function without 
interaction from other functional units. The advantage of 
this approach is that if one of the unit designs encountered 
a problem, it did not impact the others. This also allowed 
different designers to work on separate portions of the de- 
sign without concern about the impact on other areas. 

Instruction Decoding 

Because the instruction set is full and the dense encoding 
does not lend itself readily to a simplified method of decod- 
ing, previous implementations of the HP 3000 architecture 
have used specialized hardware to determine the mapping 
from the instruction to the microcode that executes that 
instruction. Generally, this hardware involves a fixed table 
of entry points in the microcode for each instruction, and 
a method of mapping the instruction encoding into this 
table. The table requires one entry for each instruction. 
However, it is frequently easier to duplicate entries rather 
than create a mapping that can resolve each instruction to 
a single location in the table, hi the HP 3000 Series 64, the 
upper ten bits of the instruction are used to address this 
table directly, so there is no logic to map instructions to a 
smaller table. This is effective for a high-performance 
machine, because time is not lost for the function of the 
mapping logic. For its predecessors, where memory compo- 
nents were more expensive and less dense, mapping logic 
was more effective. 

When placing an architecture onto a single chip, memory 



m m ~ ~~ 5 




Fig. 2. Instead of the usual arith- 
metic-logic unit (ALU), the HP 
3000 Series 37 CPU has an adder 
and a separate logic unit. 


© Copr. 1949-1998 Hewlett-Packard Co. 

and mapping logic once again become expensive, so in the 
case of the Series 37. this circuitry was eliminated. Even 
more important than eliminating the circuits was reducing 
the complexity of the design. Because it is so difficult to 
fix mistakes in VLSI designs once they have been built, it 
is important to use a methodology that is conducive to 
error-free design. Special instruction decoding and map- 
ping circuitry must be accompanied by logic to alter the 
normal sequence of microinstruction execution. Determin- 
ing whether the next microinstruction address should come 
from the regular microcode sequencing logic or from the 
special instruction lookup logic is a complex, error-prone 
task. However, eliminating the special decode function is 
expensive in performance because it adds the time required 
to decode an instruction in microcode to the execution 
time of each instruction. 

It was necessary to find a method of decoding instruc- 
tions that is both simple and fast. A jump table is a simple 
method of decoding, but it is not fast. However, by making 
decoding a fast operation while allowing other operations 
to occur in parallel, the Series 37 is able to overcome the 
inherent slowness of a jump table. To decode instructions, 
the microcode extracts the upper eight bits of the instruc- 
tion and then branches to a jump table of 256 entries. The 
most frequently executed instructions are decoded quickly 
by this method. The time required to perform the decode 
is only two cycles. It is not wasted, however, since instruc- 
tion fetch, incrementing of the program counter, and testing 
for interrupts occur in parallel with the instruction decode. 

16 Registers 

Fig. 2 is a block diagram of the CPU chip. The heart of 
the chip is a bank of sixteen registers controlled by micro- 
code. Their definition does not change from instruction to 
instruction. However, it is possible to use them as scratch- 
pad registers if the information they contain is saved else- 
where. The data contained in them is maintained by micro- 
code convention only; there is no hardware requirement 
for a particular register to contain particular data. They 
usually contain the important base register information 
needed by high-execution-frequency instructions. Not all 
of the registers can be used for any purpose whatever. In 
fact, most of Ihem double as special registers for a particular 
specialized function. See Fig. 3 for a list of these registers. 


Because the HP 3000 is a stack machine, many computa- 
tions are done with top-of-stack (TOS) data. To the pro- 
grammer, the TOS appears to be in memory, but this is 
very inefficient, so it is necessary to provide some hardware 
support for the stack. Four registers are used to contain 
(up to) the top four elements of the memory stack at any 
time. These registers, together with all of the supporting 
logic to keep track of the stack data, are contained in a 
separate functional unit. There are special operations that 
allow the microprogrammer to control these registers and 
to make the various tests necessary to implement efficient 
algorithms for their control. Thus this important function 
is retained so that performance is not compromised, yet 
the simplicity of the architecture is preserved. The TOS 
logic consists of four registers to contain data, a two-bit 

namer register to identify the data register currently named 
as the top of the stack, a three-bit stack-valid counter to 
indicate how many of the data registers contain valid data, 
and a two-bit adder to allow accessing relative to the top 
of the stack. 


One of the most powerful functional units is the extrac- 
tor. It concatenates two sixteen-bit quantities to form a 
32-bit number. Any arbitrary sixteen bits from within this 
32-bit number may be selected and then any arbitrary right- 
most or leftmost bits may be selected from this sixteen-bit 
quantity, effectively allowing the extraction and either right 
or left justification qf any arbitrary bits from a 32-bit quan- 
tity. Additionally, the contents of one of the sixteen regis- 
ters may be selectively ORed logically with the result. Al- 
though this sounds somewhat convoluted, it is actually 
quite straightforward, simple to implement, and extremely 
powerful (see Fig. 4). Its most creative use is replacing the 
instruction decoding logic found in earlier implementations 
of the HP 3000 architecture, but it is used in several other 
decoding situations as well. A target address into a jump 
table can be created in a single microinstruction and then 
control passed to that address on the next microinstruction. 

Logic Unit, Comparator, and Adder 

One of the most common operations performed in a mi- 
crocoded architecture is logical arithmetic: AND, OR, etc. 
Because these operations can be conveniently generated as 
byproducts of arithmetic operations of addition and sub- 
traction, they are usually included with the arithmetic unit, 
which then becomes the arithmetic-logic unit or ALU. The 
CMOS logic used in the Series 37 required special consid- 
erations to achieve high performance, making combining 

Register Allocation 






Subroutine- Jump 2 




Microprogram Coun(e< 


Microprogram ConMant 

Fig. 3. A bank of sixteen registers allocated as shown is an 
important part ot the Series 37 CPU chip. 


© Copr. 1949-1998 Hewlett-Packard Co. 

Using a Translator for Creating Readable Microcode 

The HP 3000 Series 37 Computer is built around a very power- 
ful, flexible microprocessor Because of this flexibility, Ihe control 
language for the microprocessor is complex and can be hard 
to understand. 

The major feature that makes the code difficult to read is the 
ability to do many different operations concurrently. One instruc- 
tion can simultaneously increment, do logic operations, add. and 
do an IF-THEN-ELSE control branch Clearly, it is important for the 
microprogrammer to keep track of all of these simultaneous op- 

To make line-by-line analysis in a debugging environment 
easy, a very rigid 17-field source language was developed to 
express these constructs (see Fig 1) However, none of the 
system microcode was written in this form Although allowing 
easy analysis of what the micromachine is doing on any given 
clock, the splitting of a single function into multiple fields and 
then interleaving these fields with other operations makes the 
intent of the microcode almost impossible to follow accurately 

To overcome these limitations of the rigid fixed-field language, 
a much more flexible language was developed (see Fig 2) All 
of the system microcode was written in this language. Its key 
features are: 

■ Any construct can be expressed (the microprogrammer is not 
limited by the language) 

■ The language is free-field Spacing, column alignment, and 
the positions of new lines and/or comments are not important 

■ The language allows an operation-by-operation expression of 
what is coded (the dec function m Fig 2 is expressed indepen- 
dently of the ADD function) 

• The user can DEFINE registers and constants to improve reada- 


LOOP R1 R2 RO R9 -1R0 SZL Z5 S5 R1 JL = 0 RB R15 LOOP 

Top Lino: Field Names 
Bottom Line: Typical Instruction 

Fig. 1 . Fixed-field source language specification. 

Objecl Code Fued-Field Source Language 

Define Counter - RO, 

Left = R1, Right =R2; 


Dec (counter) - > counter/ 
Add(R10.R11) ->ADR/ 
ExtractR (Left 1 1 Right (10 . 20)) - > Left/ 
If Logic = 0 then ReturnSubl else Loop; 

Undetine counter, left, right; 


"compute address w/ADD 
'use extractor 

Fig. 2. Flexible language used for writing system microcode. 

This free-field language is implemented as an independent 
source-language preprocessor. It is designed to complement, 
rather than replace, the fixed-field language. This preprocessor 
(known as the Translator) converts the microprogrammer-written 
source code into the fixed-field language. This is then assembled 
using a separate assembler into executable object code. The 
powerful user-del ined-command (UDC) capability of the HP 3000 
has been used to make these two tools appear to the user as a 
single well-integrated one. The final assembly listing (see Fig. 3) 
contains the source code as written, the translated fixed-field 
code, and the emitted object code, all presented in a format that 
is easily read and understood by the microprogrammer. 

Skip La Fetra 
Project Manager 
Computer Systems Division 

Source I 


Delme Counter - R0, 

Left = Rl, Right = R2; 


'compute address w/ADD 

0000 1207 0555 1880 FFFF i LOOP Rt R2 R0 R9 - t R0 SZL Z5 

S5 R1 JL-0 R8 R15 LOOP 


Dec (counter) - > counter 
Add(R10,R11) - > ADR 
ExtractR (Left II Right ( 1 0. .20)) - > Left 'use extractor 
l1Logic»OtlienRetumSub1elseLoop; 'IF THEN. ELSE 

Undefine counter, left, right; 

Fig. 3. Final assembly listing shows source code as written, translated fixed-field source lan- 
guage code, and object code. 

these two functions difficult. Also, an arithmetic unit that 
can both add and subtract requires more circuitry than one 
that can only add. Therefore, no subtract function is avail- 
able to the microcode: only add is available. Instead, a 
separate logic unit provides the functions normally associated 
with an ALU. including the one's complement necessary 
for subtraction. To subtract, the microprocessor must form 
the one's complement of the subtrahend and add it to the 
minuend with a carry. Because subtract is a relatively in- 

frequent operation, performance impact is minimal. 

In examining the functions normally performed by mi- 
crocode to implement instructions, it was discovered that 
the arithmetic functions are used primarily for comparing 
and not for arithmetic. This comparing is generally a com- 
parison of an address with certain bounds registers to see 
if the address lies within die area that can be accessed by 
the user. If it is not, a bounds violation is generated by the 
microcode and the software aborts the program that is run- 


© Copr. 1949-1998 Hewlett-Packard Co. 

Initial 16-Bit 

Registers Concatenated 


Any Arbitrary 16 Bits f) 

Any Arbitrary Upper 
(Lower) Bits Masked 

000000000 , 110O00O10O0OO0OO 

Another 16-Bit Register Is ORed 

The 16-Bit Result 




0 0 0 0 



ning. Typically, previous HP 3000 machines have special 
hardware circuitry to examine the carry signal from the 
ALU and force the microcode to specific error addresses 
when a compare indicates a bounds violation. In keeping 
with the philosophy of simplicity and explicit microcode 
control of the machine at all times, hardware to force certain 
microcode addresses was summarily rejected. Instead, a 
simple comparator circuit is included, allowing a quick 
comparison of two addresses and a transfer of control based 
on the result. 

The specialized comparator circuitry, which is com- 
pletely self-contained, is able to perform all of the necessary 
bounds checking with no performance penalty. 


Although the microcode seldom needs to perform arith- 
metic beyond addition, it frequently needs to either add 
or subtract one from a number. To provide this capability, 
an incrementer/decrementer is available and can be used 
on every cycle. This proved to be one of the most valuable 
additions to the design, because it allows an arithmetic 
operation to occur in parallel with a separate logical oper- 
ation. The incrementer can perform four functions: add 
one. subtract one, pass unchanged, and add two. 

One useful function of the incrementer is to simulate 
subroutines. Because the microprogram counter is a register 
like any of the other registers, the incrementer can pass its 
value to one of the subroutine jump registers easily. If the 
incrementer is needed on the line that jumps to the sub- 
routine, it can pass the microprogram counter incremented 
by one on the line before, or by two on the line before that. 
The return from a subroutine is accomplished by select- 
ing this register as the next address for the microprogram 

Microcode Address Selection 

The next line of microcode to be executed is selected 
from one of four registers by the current line. Two fields 
in the microinstruction specify the next line of microcode; 
these are the true target and the false target fields. There 
are 32 conditions that can be tested by each line of micro- 
code. If the condition is met, the address for the next line 
of microcode comes from the register specified by the true 
target field. If not. the address comes from the register 

Fig. 4. The extractor, a functional 
unit of the Series 37 CPU chip, 
replaces the instruction decoding 
logic found m earlier HP 3000 

specified by the false target field. Each bit in the flag register 
can be independently tested, as can sixteen other condi- 
tions and bits in the machine. The four registers that can 
be used as the source for the next address are the micropro- 
gram constant (useful for jumps to specific addresses), the 
microprogram counter register (executing microcode in se- 
quence), and the two subroutine-jump registers. The sepa- 
rate true and false targets allow complete symmetry as well 
as the freedom to execute either of two lines, neither of 
which is the next line in sequence. 

Diagnostic and Test Capability 

Because all of the registers are easily accessible and there 
is very little specialized hardware, the design does not 
require much additional circuitry dedicated to diagnostic 
test purposes. There are special commands allowing access 
to bits that could not otherwise be accessed, but no other 
specialized logic. This makes testing a straightforward task 
instead of the labyrinthine jumble of convoluted code re- 
quired with conventional designs containing a multiplicity 
of untestable bits. Since each of the functional units has 
limited well-defined side effects, it is easily verified that 
a failure of one of these has occurred, and that no others 
have failed. 

Performance Results 

The HP 3000 Series 48 provides a good comparison for 
the design of the Series 37. Although the Series 48 has 
specialized hardware to help with instruction decode and 
bounds checking, it is basically a much simpler design than 
the Series 68 and contains far fewer circuits. Measured in 
the same terms, it contains about twice the circuitry of the 
Series 37. Therefore, it is of particular interest to compare 
the relative efficiency of the two designs. Because the mem- 
ory reference instructions are so critical in the instruction 
mix, it is especially worthwhile to compare these instruc- 

The Series 37 has an immediate disadvantage compared 
to the Series 48 because it does not have special instruction 
dm ode i:in uitry. Sim r this linn linn is extw llted by inii.m- 
code. it must be slower. Also, there is no hardware prefetch 
of the following software instruction as in the Series 48, so 
this must also occur in microcode. Consequently, the first 
few cycles of every instruction are spent initialing a memory 


© Copr. 1949-1998 Hewlett-Packard Co. 

Booting 64-Bit WCS Words from a 
32-Bit- Wide ROM Word 

The processor design tor the HP 3000 Series 37 Computer 
emphasizes small size, low cosl and reliability. To realize this, 
the computer is designed with lew parts and without the separate 
control processor used on other members ol ihe HP 3000 product 

Because the Series 37 does not have a separate control pro- 
cessor to load WCS before launching the main processor, Ihe 
mam processor musl load its own microcode It does this by 
executing a short power-up program directly from ROM whose 
sole purpose is to initialize the writable portion of control store. 

The Series 37 requires four ROM chips to hold all of the cold- 
load and self-tesl microcode These chips hold 128K bits of 
information each. However, eight ROMs would be required, each 
supplying eight bits of data al a time, to supply Ihe lull 64-bit 
microinstruclion word required to run the processor To avoid 
Ihe need for these extra four ROMs, a scheme was devised that 
allows Ihe processor to boot wilh only 32 bits of each microin- 
struction supplied 

This scheme is simple in principle: choose a subset of the 
processor's capability thai is adequate to boot ihe system bul 
simple enough lhal it can be expressed with 32 or fewer bits of 
microinstruction, and then force the unused 32 bits of Ihe 64-bil 
control word to constant values. For example, Ihe CBUS field 
allows access lo all 16 internal registers (requiring four bits of 
control) The boot code only uses two ol these registers. By lying 
three conlrol lines to a constant zero we require only one bil ol 
ROM control for the CBUS field Similar reduction ol conlrol re- 
quirements was done with each microinstruction field as follows 



of 4 

bits used 



of 4 

bits used 



Of 4 

bits used 



Of 2 

bits used 



of 2 

bits used 



of 4 

bits used 



of 1 

bit used 



of 12 

bits used 



of 4 




of 1 

bit used 



of 6 

bits used 



of 4 

bits used 



of 16 

bits used 


of 64 


The limited capability provided by this control is enough to 
step byle-by-byle through one ROM and transfer its contents lo 
writable control store After confirming that the microcode was 
successfully transferred, control is passed to Ihe newly loaded 
code. This code is of full 64-bit width and has all ol the power 
ol Ihe processor available to it Thus il has the capability lo run 
extensive microdiagnostics, load more microcode from the other 
three ROMs, and boot Ihe operating system 

Skip La Fetra 

Project Manager 
Chris Shaker 
Development Engineer 
Computer Systems Division 

fetch of Ihe following instruction and decoding the current 
instruction. By using Ihe capability of the extractor, the mi- 
crocode is able to decode an instruction and transfer to Ihe 
first line of the instruction wilh only three cycles of over- 
head. The first cycle extracts Ihe upper eight bits of Ihe 
instruction and combines them with the address of the jump 
table, storing this final address into a jump register. The 
second cycle transfers control lo the address specified in 
the jump table. The third cycle is the line of microcode in 
Ihe jump tabid thai transfers lo the instruction itself. This 
third cycle can also begin execution of the instruction, thus 
reducing the effective overhead. 

Il would seem obvious that with a three-cycle overhead, 
the instruction must be slower than its counterpart on the 
Series 48. Indeed, the performance of the Series 37 is less 
than that of the Series 48. but this is because of the Series 
37's lower clock frequency and not the efficiency of the 
microcode. Comparing the number of cycles required to 
execute the instruction rather than the amount of time, the 
surprising result is that the Series 37 memory reference 
instructions require approximately the same number of cy- 
cles as the Series 48. When the overall performance of the 
entire instruction set is compared, the Series 37 and the 
Series 48 require approximately the same number of clocks 
to execute a typical mix of instructions for Ihe HP 300(1. 

Although Ihe amount of logic is far greater to realize an 
architectural implementation for the Series 48 compared 
to the Series 37, the relative amount of work done for each 
machine cycle is the same. The simple approach used in 
the design of the Series 37 resulted in an extremely efficient 
use of silicon. A design need not be complex to be COSt- 


There were a number of people whose dedication and 
patience made this design possible, and incredibly in less 
than six months from initial concept lo final tape release. 
Paul Smythe and Greg Gilliom led the microcode effort 
working with Brian Feldman and our prolific summer stu- 
dent, Michael Goo. Norm Galassi generated the test micro- 
code which was successfully used in the simulations to 
ensure lhal Ihe first-pass chips were Ihe last-pass chips. 
Karen Murillo designed several oi Ihe functional units on 
the chip. The tools were created by Frank Hublou. who 
made sure thai there were no problems interfacing with 
any of the other groups with whom we worked, and Daryl 
Allred, who was able to respond to the many requests for 
specialized tools in a remarkably short time. Special recog- 
nition is due Barn,' Shackleford, without whose encourage- 
ment, insistence on maintaining simplicity, and dedication 
to excellence in organizing and leading the design, this 
project would not have been possible. 


© Copr. 1949-1998 Hewlett-Packard Co. 

Simulation Ensures Working First-Pass 
VLSI Computer System 

by Patria G. Alvarez, Greg L. Gilliom. John R. Obermeyer, Paul L. Rogers, and Malcolm E. Woodward 

ONE OF THE OBJECTIVES for the HP 3000 Series 
37 project team was to produce two fully functional 
VLSI chip designs, each in a single pass with no 
errors. The advantages of this objective are obvious. With 
first-pass chips, the project schedule is shortened consid- 
erably, leading to lower project costs. This also frees labo- 
ratory resources to be applied to the next project sooner. 

This goal seemed formidable when first proposed, since 
it had never been done before at HP's Computer Systems 
Division. Formerly, all designs were done in several passes: 
a breadboard, a lab prototype, and a final-release version. 
At each stage, the design was fine-tuned to match the 
specifications of the project. 

To release single-pass designs required careful investiga- 
tion and thorough definition before the logic was laid out. 
Gate arrays were chosen for the two chips, and their simple, 
regular architecture was a strong ally in the construction 
of first-pass chips. However, the tool that absolutely 
guaranteed first-pass VLSI chips was the design simulator, 
FTL. By using a simulator capable of logic and timing simu- 
lation, the project team was able to detect errors before a 
chip was masked or fabricated. This early error detection 
allowed faster turnaround on logic design and encouraged 
more effective verification. 

FTL is an acronym for Faster Than Light, a name given 
to the simulator by its creator. FIT. uses the output files of 
the Design Capture and Documentation Facility (DCDF), 
an interactive menu-driven logic design tool used on the 
Series 37 project to enter and generate circuit schematics. 
During the design stage of the Series 37 project, DCDF 
allowed engineers' designs to be captured for input to the 

FTL lets the user watch a design in action as inputs are 
provided. It is written in IBM 370 assembly language, and 
in our case, runs on an Amdahl V6. The Amdahl provided 
the design team with immense horsepower, greatly reduc- 

ing the time necessary to simulate the design. 
FTL Features 

FTL provides many features to assist the hardware de- 
signer in designing and debugging a circuit. It can combine 
several different design files into a single simulation, so 
thai several designers working on the same chip can simu- 
late their portions of the circuit and then combine their 
designs into a single simulation to see how the different 
parts of the circuit work together. Chip designs can then 
be combined with board logic so that entire boards can be 
simulated. Finally, several boards, such as CPU, memory, 
and I/O, can be simulated together. 

A nice feature of FTL is the ease with which a designer 
can look at a logic signal. Like a conventional logic 
analyzer, the FTL user interface is a display screen (see 
examples. Figs. 1 and 2). All signals on the screen are 
labeled with the names used in the DCDF design file. To 
view a logic signal, the engineer simply inputs the name. 
The logic signal is added to the screen, and the engineer 
can observe the logic transitions. Logic signals can be view- 
ed singly or as octal or hexadecimal representations if sev- 
eral signals are grouped in a bus structure. 

Through an addition to the simulator made specifically 
for I he Series 37 project, the design team was able to preload 
RAMs and ROMs on the board from separate files. 

CPU Chip Simulation 

The two VLSI gate array chips in the Series 37 are the 
CPU chip and anothergate array that is used in the terminal 
interface controller (TIC). 

A difficult problem for most designs of chips as large as 
the CPU gate array is the generation of good lesl vectors. 
In many cases, test vectors are painstakingly generated by 
hand, with an engineer toggling each input and observing 
the outputs to see if they respond as expected. This often 

+ 1 


+ 2 




































— + 3 + 1* 

+ 5 4 g + 7 + 

Fig. 1. Macro screen produced 
by the FTL simulator tor generat- 
ing simulation clocks tor the termi- 
nal interface controller (TIC) 


© Copr. 1949-1998 Hewlett-Packard Co. 




T W 

0.7 89 


r\ ft T ft T u 

0 DMASQ = FF 0 

















RAMIO = 00 0 

FRZ » 



0 MEMCYO-4 = 0 00000 



1000 MISC 








— ! PFW ■ 0 IRQ - 0 

=='CL0CKIN = 1 SYNC = 1 

PON 0 

'SYNCIN = 0 2XCLK = 1 


ICLKGT0-3 0000 




SCOPE* TICBD FR0M = 00 T0 = 00 

SCR= 0 





X= 1 Y = 








1 1MBRQ 





! 1 - 12345678 -- 






1 1 00000000 




'OBII . . . 



1 RWENT 1 


. 1 






IMBA0.2.4 7 


1 SMSK . . . 


1 1 - 12 

3456 -- 




IRDGT . . . 


1 1 000000 









. 0 


































































FR0M= CO T0= 00 
«CYC= 1 

SCR = 

X= 1 Y = 


Fig. 2. 'lop) FJL simulator screen 
showing overall TIC board activity, 
(bottom) FTL screen showing de- 
tailed SIMB (synchronous inter- 
module bus) activity. 

leads to bored engineers reaching a frustration limit and 
releasing a circuit before it is fully verified. 

In the case of the Series 37 CPU chip, we were building 
a machine that had its own micrucode structure. In addi- 
tion, the CPU and memory boards were also being designed 
in DCDF. so it was possible for FTL to simidate them to- 
gether. Taking this one step farther, it was possible to load 
actual microcode into simulated ROMs on the CPU board 
and execute this microcode on the simulator. Therefore, 
we used the self-test microcode for the system, which had 
to be written for later use in manufacturing and field sup- 
port, as the first test program for simulation of the design 
using FTL. The first version of the self-test was approxi- 
mately 1000 lines of microcode and took three hours to 
run on the Amdahl. Using the clues provided by this first 
simulation, the CPU designers reworked their design and 
rechecked it, while the self-test engineer expanded those 
tests into new areas of the design. This same philosophy 
was used on the memory and I/O boards. 

By modifying the FTL simulator slightly, it was possible 
to generate test vectors for the gate array chip automatically. 
The microcoded self-test was executed on FTL and the 
inputs and outputs of the gate array were recorded. These 
inputs and outputs were later used by the gate array vendor 
to verify the first prototype chips and to verify the chip 
timing and parameters using the vendor's simulation 
equipment. The vendor's simulation after routing and 
masking of the chip led to the final timing specifications 
for the chip. 

TIC Gate Array Simulation 

The other gate array in the Series 37 system, a 4000-gate 
VLSI chip, is used in the terminal interface controller (TIC). 
The entire TIC, including the gate array, was designed in 
DCDF and simulated using FTL. In the TIC case, the chip 
is not a processor capable of executing a self-test. Instead, 
it consists of several complex state machines and control 
logic. To simulate it. a special assembler was written that 
made it possible to write a verification test in a simple, 
high-level language that corresponds to the functional op- 
eration of the chip. The assembler translated the high-level 
functions specified into the proper inputs for the chip. This 
verification test was then executed in a pseudoboard envi- 
ronment created to aid in the simulation. Around the VLSI 
TIC chip was added a sequencer, a RAM to supply the 
input signals, the DMA state machine ROMs, and the TIC 
register RAMs (see Fig. 3). The DMA state machine ROMs 
were loaded with the state machine control. The input 
control RAM was loaded with the patterns from the assem- 
bler and was accessed via the sequencer. The test vectors 
for the gate array chip were collected from the chip inputs 
arid outputs during this verification test. The assembler 
made it feasible to generate an exhaustive set of test vectors 
for the gate array. Thus it was a major factor in the design 
of a first-pass TIC gate array chip. 

As a result of these methods and tools, the CPU and TIC 
gate arrays had only one design pass. The chip designs 
used in the first hardware breadboards are still used today 
in production units. The next step was to achieve the same 
results at the printed circuit board level. 


© Copr. 1949-1998 Hewlett-Packard Co. 

Fig. 3. Pseudoboard environment created to aid in the simu- 
lation ot the VLSI TIC (terminal interface controller) gate array 

Models Created 

Before simulation of any of the boards could begin, we 
had to create models for each of the TTL and CMOS p. iris. 
PLAs, and other special parts used in the design. The mod- 
els had to be understandable to (he FTL simulator. Some 
basic building blocks were created to aid in the modeling 

of standard logic parts. These basic blocks were generic 
OR. AND. and XOR gates and various types of flip-flops and 
memory elements. Each standard part was modeled using 
these basic blocks. Then the model was verified by testing 
just thai part using FTL. This process was tedious, but 
necessary to ensure the accuracy of the system simulation. 

The next step was lo simulate each of the printed circuit 
assemblies and custom VLSI chips separately. All of the 
printed circuit boards and custom VLSI chips were simu- 
lated more or less in parallel by the individual design 
teams. FTL lends itself to parallel simulation, thereby sav- 
ing a great deal of time. The custom VLSI CPU gate array 
chip was simulated first, as described previously. After 
this simulation was complete, the next step was to begin 
simulation of the CPU board. 

In simulating the CPU board, first the clocks were con- 
nected to the board. An 8* clock drove the CPU clock as 
well as the system clocks. This clock. 8XCLK. was the driving 
clock used during simulation. For each eight ticks of 8XCLK. 
there was one tick of the CPU clock (CLOCK). The screen 
of the simulator was set up so that the particular nodes 
being tested were displayed on the screen. Any of the nodes 
on the board could be displayed. Once the screen was set 
up, the inputs to the particular subassembly of the CPU 
board were put into their desired states. Then the required 
number of clock cycles was entered (eight for one CLOCK 



4f ¥ 

t » 




Fig. 4. An ALD schematic ALD stands for Automated Logic Drawings, a subsystem ot the 
Design Capture and Documentation Facility (DCDF) used in the design of the VLSI chips tor 
the HP 3000 Series 37 Computer DCDF output files are the inputs to the simulator, which is 

called FTL 

© Copr. 1949-1998 Hewlett-Packard Co. 


cycle), and the simulation was begun. Once simulation had 
ended, the final state of each of the nodes on the screen 
was displayed. No intermediate results were available. If 
intermediate results were desired, the number of clock cy- 
cles to simulate could be reduced. 

Once all of the subassemblies had been simulated, the 
processor gate array was connected to the CPU board, and 
the simulation of the entire CPU began. This was done by 
loading test microcode into the simulation control store 
memory. At this point the microcode controlled the oper- 
ation of the CPU. so that different code was written to test 
the different functions of the CPU. 

After the CPU and memory simulations were completed, 
the CPU and the memory were simulated together. The 
peripheral interface channel (PIC) was added to the system 
simulation model after the CPU/memory simulation had 
been completed succesfully. Finally the TIC was added to 
the system simulation model after the CPU/Memory/PIC 
simulation and the VLSI TIC gate array chip simulation 
had been completed. 

During every phase of the simulation, designs were cor- 
rected or modified as necessary to ensure correct operation 
of I he system. The result of the individual and system 
simulations was a set of first-pass printed circuit boards 
that were able to run as a computer system. Both of the 
custom VLSI chips also worked on the first pass. This is a 
major accomplishment and was only possible with the help 
of FTL and Delay, a timing analysis program. 

The full system simulation model was used even after 
the first successful printed circuit boards were up and run- 
ning. The system model was used to check out new or 
anticipated changes to the system before they were ever 

Providing Documentation 

During the design stage, as the Design Capture and 
Documentation Facility captured the engineers' designs, 
ALD (Automated Logic Drawings), a subsystem of DCDF. 
provided documentation in the form of schematics. DCDF 
runs on an Amdahl 470 Computer. Through an MRJF link, 
the schematics are transferred to a remote HP 3000 Com- 
puter and are printed out on an HP 2680A Laser Printer. 

With the facilities available through DCDF. complete and 
up-to-date documentation can be attained anytime a new 
design is created or a modification is made. 

Schematic Generation 

Fig. 4 shows an example of an ALD schematic. A feature 
of ALD is its autorouting facility. All of the circuit blocks 
on a single ALD page having the same interconnect are 
automatically routed together. ALD gathers all connectivity 
information from the DCDF file and automatically routes 
one signal line to another. Routing executes a variation of 
Lee's algorithm 1 2 using direction numbers. The algorithm 
finds the paths for routing the signals in the design. 
Through the routing facility, an engineer can specify the 
maximum number of bends in the line joining the signals. 
Should the autorouter not find enough room to draw a wire 
lrom one gate to another, the line is not drawn, although 
the signal name of the line is shown so it is not mistaken 
for no connection. 

All logic symbol pictures come from a master library or 
catalog. For example, when a NEW command is executed 
from the DCDF gate editor, an element with the number 
specified is fetched from the catalog. A pictorial description 
of that element and other documentation elements (BLOCK 
TYPE and BLOCK NAME) are brought to the terminal screen. 
All design elements are automatically given a default name 
as they are inserted in the design, but at any time the 
engineer can replace this default name with a user name. 
The designer may place the logic symbol at any valid loca- 
tion on the schematic, and when it is printed, the picture 
appears with the default or given block name. 

The schematics generated by ALD are typical of most 
schematics, but they also provide the following: 
t» Global comments: A designer's personal comments can 

be included on the schematic and placed and displayed 

as desired. 

" Title blocks: A box is automatically placed in the corner 
of a schematic. Information such as designer name, block 
name, and block function can be placed here. 
Hierarchy information: Hierarchy information is pro- 
vided by ALD so that a designer can tell what level of 
the design is being displayed. 

n Cross reference: The cross reference generates a symbol 
table listing for bus cross references and connectivity 
reports. It includes a list of the external signals to the 
circuit, and it includes the interface signal name, connec- 
tor pin number, and signal nature. All the interconnects 
in the schematic are alphabetically listed with all the 
connection points where that signal is attached. 
The following is a sample cross reference: 

+ MPY_IN<*> 




M 20 1 OUT - OUT <0> 
L 20 47 OUT +Q <0> 
G 64 1 IN ^D_0<0> <0> 

In this list, GATE-NAME refers to the name of the gate where 
the connection is made. X is theX location of the connection 
point based on a scale printed on the schematic, Y is the 
Y location of the connection point based on a scale printed 
on the schematic, PG is the page of the schematic where 
the connection point is located. TYPE is the type of connec- 
tion point (input, output, bidirectional). CP is the internal 
pin designator for the node, and BUNDLE is used to show 
which interconnect signals from the bundle are attached 
to the node. 


We would like to acknowledge Daryl Allred for the work 
he put into all of the design tools (DCDF. FTL. Delay) so 
they could be used in the design of the Series 37. The CPU 
self-test and test vectors were contributed by Norm Galassi. 


1. M.A. Breuer, Design Automation of Digital Systems. Volume I: 
Theory and Techniques. Prentice-Hall. Inc.. 1972, pp. 312-313. 

2. J.H. Hoel, "Some Variations of Lee's Algorithm." IEEE Transac- 
tions on Computers. Vol. C-25, no. 1. lanuary 1976. pp. 19-24. 


© Copr. 1949-1998 Hewlett-Packard Co. 

Creative Ways to Obtain Computer System 
Debug Tools 

by William M. Parrish, Eric B. Decker, and Edwin G. Wong 

puter system, it is imperative that the problem be 
found and corrected quickly. A determination of 
whether the problem is in the hardware or the software 
must be made, and the faulty hardware or software module 
must be replaced. In the HP 3000 Computer, a major diag- 
nostic tool is the maintenance panel or debug panel. In the 
HP 3000 Series 37, an off-the-shelf microcomputer is used 
for the maintenance panel. For software diagnostics, the 
standard HP 3000 debugging facilities are supplemented 
by a virtual software debugging panel called SoftPanel. 
which is implemented in microcode. The maintenance 
panel requires extra hardware and is used in the factory 
and optionally in the field. SoftPanel is a built-in tool, 
available in any system at any lime. 

System Consoles 

Historically. HP 3000 systems have had consoles that are 
combinations of hardware and firmware. These devices 
provide operator functions such as loading, starting, and 
dumping the system, routine diagnostic functions such as 
running built-in self-tests and checking hardware I/O con- 
figurations, and firmware, hardware, and software debug 

The earliest consoles consisted of a special interface card 
on the CPU backplane and large assemblies of LED indi- 
cators and switches. On the HP 3000 Series 11 and III, these 
consoles were made service-only tools, and the operator 
functions were put into smaller panels which were actually 
shipped to customers. If the diagnostic capabilities of Ihe 
maintenance panel are required, a Customer Engineer 
brings the panels to the customer site and connects them 
with several bulky cables. 

Later consoles, those for the Series 44 and 64. for exam- 
ple, also use a special interface card on Ihe CPU backplane, 
but are designed to work in parallel with Ihe MPE system 
console. A special sequence of characters is employed to 
get the attenlion of the maintenance panel functions, and 
the commands can be entered through Ihe same terminal 
used for the MPE console and the operator's session. 

The Series 64/BH. with its large number of assemblies, 
requires all boards on the CPU backplane lo conlain shift 
strings, which can be read out and written by the console 
(known as the Diagnostic Control Unit, or DCU) to allow 
detailed troubleshooting of the different assemblies and 
data paths. By this mechanism, information contained in 
storage elements on any assembly can he read and mod- 
ified. Special micmdiagnostics can be loaded through a 
flexible disc drive connected to the console terminal. 

Series 37 Requirements 

The Series 37 is designed to be a high-volume. low-cost 

system relative to other HP 3000 systems. As such, we 
needed to minimize the special hardware required for the 
console. We also had to have the debugging system avail- 
able almost immediately after the receipt of first VLSI parts, 
so there was not a lot of time in the schedule to debug our 
debugging system. 

The hardware of the Series 37 consists of a small number 
of field-replaceable units. Sophisticated shift-string capa- 
bility, such as was provided by the Series 64 DCU, was not 
appropriate. If a hardware problem develops in Ihe field, 
there are few enough (and inexpensive enough) field-re- 
placeable units in the Series 37 that a temporary exchange 
of SPUs (system processing units) can show whether a 
problem is with intermittent hardware or a design problem. 
Hardware and microcode design problems should be found 
and corrected in the factory, not the field, so such tools 
were deemed unnecessary in the product. 

It was decided, therefore, to partition the console func- 
tions into functions required in the product and functions 
required in the factory. Functions required in the product 

" The ability to LOAD. START, and DUMP the system 
" MPE console capabilities 

■ Remote console capabilities 

■ Ability lo run built-in and external software diagnostics 
and check Ihe hardware I/O configuration 

■ Ability to look at and modify software registers and main 
memory (SoftPanel functions). 

Functions not required in Ihe final product, but required 
for bringing up the system and factory debug include: 

Fig. 1. An HP 9000 Model 236 Computer serves as the 
maintenance panel lor the HP 3000 Series 37 Computer 

© Copr. 1949-1998 Hewlett-Packard Co. 


■ The ability to load a microcode image into control store 

■ The ability to read and modify writable control store 

a The ability to read and modify registers used by the 

■ Breakpoint in control store 

■ The ability to do I/O commands on the synchronous 
intermodule bus (SIMB) 

■ The ability to do 32-bit writes and to read error status 
information from the memory subsystem. 

The microcode and software teams, being the primary 
initial customers for the maintenance panel, had consider- 
able interest in the specifications for the tool. Their inputs 
caused us to come up with the following constraints: 

■ The major CPU registers should be visible on the screen 
at the same time and should be updated automatically 
as execution progresses. The contents of the screen 
should reflect the state of the micromachine when micro- 
code execution is interrupted by the maintenance panel 
or while microstepping through microcode. Since the 
CPU contains 15 high-speed registers plus a number of 
register-file locations that are frequently updated by mi- 
crocode, it was deemed necessary to use a product with 
a large enough screen to display all of these registers. 

■ The microstep function, including screen updating, 
should occur in about a second or less. 

0 Full support of the SIMB breakpoint board should be 
provided, including use of the range and data pattern 
features (see box. page 20). 

u The microcode required for support of the maintenance 
panel should be small enough to be debugged easily with 
the microcode simulator tools, so that it could be fully 
tested before committing it to ROM. 

■ A means of loading initial microcode and memory im- 
ages was needed. Since the microcode files were de- 
veloped on an HP 3000 Series 64, and the cold-load 
microcode was not to be initially available, a means of 
transferring such data from the development system to 
the new hardware had to be developed. 

Series 37 Maintenance Panel 

The HP 9000 Model 236 Computer (formerly HP 9836] 
was chosen as the maintenance panel (Fig. 1). It has a large 
enough screen to display all relevant registers. Its high-per- 
formance CPU and BASIC operating system are fast enough 
that I/O and the screen updates required for a microstep 
occur in about one half second. It supports HP's LIF (logical 
interchange format), allowing a limited file transfer capabil- 
ity from the HP 3000 via flexible discs. 

It was initially unclear whether interpreted BASIC had 
sufficient performance to provide a one-second microstep. 
Early in the development, we wrote an experimental screen 
update program (not including I/O to the Series 37) and 
determined that screen update and data formatting times 
would not be limiting factors. The I/O lime to read the 
required registers over the parallel interface was computed 
and it was determined that we would be able to meet the 
specification of a one-second microstep time easily. 

The required functions were implemented in a combina- 
tion of hardware and firmware. The remainder of this arti- 
cle describes the implementation and functionality of the 
bring-up and debug tools. 

Maintenance Panel Hardware 

The hardware required for the Series 37 debug panel 
includes an HP 9000 Model 236 Computer with 768K bytes 
of memory and an HP 98622A GPIO Interface card (16-bit 
I/O plus handshake lines). This card resides in the Model 
236 card cage. A custom cable connects the Series 37 CPU 
board to the CPIO card. A connector and drivers for the 
debug console are standard on every Series 37 CPU board. 
The optional SIMB breakpoint board is required to set 
breakpoints in main memory. This board requires a card 
cage slot in the Series 37 Computer. 

The mechanism for entering the maintenance panel code 
is a process known as "force magic data." This is a means 
of breaking the microinstruction stream that is executing 



961 E 

SJl R8: 






ADR R9: 






ADN R10: 






AUG Rll: 







STA R12: 







FLG R13: 







HPC R14: 







CON R15: 





MUR: FF03 90FF 6898 FFFF 
R1O15R0^^MR0^RrT , If7 

>0: n 






BT: 0 






DV: 0 




LP : 


L0: D 






FC: a 






10: 0 




CT: 0 






SB: 0 










SR: 0 









8001 P 


TOSD: 0000 



R6 JBT R7 R14 »0000 FFFF FFFF 




<WCS flDDR > [ ,<DEC COUNT) ) [;T] 

Fig. 2. Maintenance panel firm- 
ware display 


© Copr. 1949-1998 Hewlett-Packard Co. 

and passing control to maintenance microcode. The mech- 
anism works by forcing a particular data pattern onto the 
microinstruction bus. causing a branch to a particular ad- 
dress in the control store. This mechanism is implemented 
in hardware on the Series 37 CPU board. It should be noted, 
however, that this mechanism is used for handling micro- 
interrupts other than the maintenance panel, and hence is 
not unique to the debug panel. 

Maintenance Panel Software 

The software in the Model 236 Computer consists of a 
BASIC program, which uses Advanced BASIC constructs 
to control the displays, process commands, and handle 
interrupts from the user and the Series 37. The BASIC 
software is partitioned into user interface portions and I/O 
portions, allowing us to be flexible in defining new user 
commands as required during development. 

The user normally sees one of two screens, a firmware 
display or a software display, providing two viewpoints 
into the machine. The firmware display (Fig. 2) provides 
a window into the micromachine. including the state of 
the firmware registers at the last invocation of maintenance 
mode, along with the currently executing microword in hexa- 
decimal format and disassembled symbolically. The address- 
es of microbreakpoints currently set are also displayed. 

The software display (Fig. 3 ) shows the HP 3000 program- 
mer's view of the machine (i.e.. the state of the mac- 
romachine). The display is arranged to show information 
about the code (PROGRAM) currently running, the stack, 
and global and status information. A display of the lop 24 
stack locations is shown at Ihe bottom of the screen. The 
TOS cache is transparent to the user in this mode; in the 
firmware display, it is not. 

Maintenance Panel Firmware 

The work of obtaining and modifying values in memory, 
registers, and the SIMB is done by a small set of microcode 

routines. Two sets of these routines exist; one set is in 
ROM. and another set overlays the ROM routines when 
the operating system is running. 


During normal system operation, the Model 236 can be 
connected to the Series 37 CPU board and the impact is 
minimal, The power-on self-test code checks for a mainte- 
nance panel, and causes Ihe panel to become active before 
attempting to prompt the user for START LOAD DUMP com- 
mands. Following that, if the system is operated normally, 
the Series 37 user will not be aware that the panel is con- 
nected to the system. 

If certain microinterrupts occur, indicating hardware 
problems, the panel will gain control if it is connected. 
Alternatively, the user can hit the HALT key and force the 
machine to stop. 

While in maintenance mode, the user can issue com- 
mands to the Model 236 which are formatted into data 
patterns and sent out over the GPIO card to effect the vari- 
ous user commands such as Modify Register or Display Memory. 
These data patterns are interpreted by the firmware, which 
invokes microsubroutines to make the changes occur in 
the Series 37 CPU environment. Operations on the registers 
normally used by microcode are performed on shadow reg- 
isters while in maintenance mode. 

To terminate maintenance mode and resume normal 
execution, the user presses the CONTINUE(URUN) softkey. 
which sends a command over the GPIO requesting micro- 
code to restore the state from the shadow registers and 
resume where execution was left off. 


A breakpoint was defined in control store by use of the 
WCS parity error interrupt. A breakpoint in control store 
is set by changing the parity bit; the Model 236 keeps a 
list of locations thai have been so modified. The microcode 




M ; m 1 

HI T R 0 C 








y y e o i i 

STA : 177777 





ICS : 12S340 
DSP : 0S2741 




I : 052753 





(T0S-Z27) 038370 838370 838378 838370 838378 838378 830370 030370 
(T0S-U7 ) 838378 838370 830378 838378 830378 838378 838378 030370 
(T0S-X7) 838378 830378 838378 838378 838378 838378 838378 838370 

UHLT 11:24:13 


Fig. 3. Maintenance panel soft- 
ware display. 

© Copr. 1949-1998 Hewlett-Packard Co. 


The Role of a Programmable Breakpoint Board 

In a microcode and software development environment, one 
of the problems difficult to debug is the case when memory 
locations appear to contain Ihe wrong data. This normally occurs 
when a bug in software or microcode causes an illegal write to 
Ihe suspected memory location These so-called memory hits 
may happen at just one memory location, within a range of loca- 
tions, or over the entire range of the memory They may happen 
with a fixed data pattern or in a random pattern. They may happen 
often or occasionally. 

A simple approach to the solution of this problem is to connect 
a logic analyzer to the CPU bus and program the analyzer lo 
trigger and record the bus transactions when an access to the 
suspected memory location happens. There are a few drawbacks 
to this approach. One ma|or drawback is the fact that the logic 
analyzer just captures what appears on the bus and cannot 
freeze the CPU for further examination of the internal CPU regis- 
ters and flags The other drawback is that this approach is not 
friendly and requires specific knowledge of the hardware to con- 
nect the logic analyzer, a task thai most software developers 
and microcoders try to avoid A better solution to this problem 
is to design a board that resides in the computer system like 
any other board and does the 10b of a logic analyzer. The advan- 
lage of this approach is that no analyzer needs to be connected 
and programming is through normal computer instructions. 

For the HP 3000 Series 37 Computer, a special breakpoint 
board was developed to provide memory transaction monitoring 
capabilities to the system. This board is a programmable I/O 
channel that is plugged into the system like any other board and 
monitors memory transactions Normally, it is transparent to Ihe 
system and does not interfere with the normal system operation 
except at system initialization, when it responds to the SIMB 
ROCL (roll call) instruction to indicate its presence The program- 
ming is through SIMB WlOA (write I/O adapter) commands issued 
to the board to set its internal registers Therefore, programming 
can be done using any facility capable of issuing SIMB com- 
mands, including an HP 9000 Model 236 Computer or SoftPanel's 

The breakpoint board consists of nine write-only and three 
read-only registers. The write-only registers include two bank 
and address registers. Iwo data registers, two opcode registers, 
and one control register The board is configured by writing into 
the control register The bank and address registers can be 

for handling WCS parity interrupts includes going through 
the "force magic data" process and subsequently checking 
for the presence of the Model 236. When the Model 236 
sees an interrupt from a WCS parity error, it checks to see 
if the location is one it knows to be a breakpoint. If so, it 
treats the interrupt as a breakpoint, and indicates this to 
the user. If not, it treats the interrupt as a valid WCS parity 
error, and indicates this to Ihe user. 

With this general process, it was possible to create in 
BASIC an arbitrarily large breakpoint table (we had eleven 
entries: one special-purpose and ten general-purpose). It 
was also possible to create temporary, permanent, and 
counting breakpoints by changing only BASIC code. Wilh 
the programmable BEEP statement, an ALARM function is 
provided: a short beep for a hit on a counting breakpoint 
(different tones for different breakpoints), and a warble for 
a complete step on expiration of a breakpoint. 

The special-purpose breakpoint is used to implement 

programmed to break on individual addresses or on any address 
between two limits (range mode) The data registers can be 
programmed to break on patterns of 1 . 0, or X (don't care) bus. 
The read-only registers capture the from CODE bank, and ad- 
dress of the breakpoint event 

Once Ihe board is programmed, it compares every memory 
transaction thai appears on the SIMB with its internal registers 
When a match occurs it sends a nonmaskable Interrupt (SIMB 
WARMSTART) to Ihe CPU Upon receiving this interrupt Ihe CPU 
virtually freezes and executes special microcode thai per- 
mits the examination of Ihe CPU internal registers and flags by 
SoftPanel or ihe maintenance panel s Model 236 Compuler The 
SIMB information lhal caused Ihe break (memory address, SIMB 
from CODE, and SIMB OPCODE of the transaction) are all cap- 
lured in Ihe internal registers of the breakpoint board and can 
be accessed by issuing ihe SIMB RlOA (read I/O adapter) com- 
mand lo Ihe breakpoinl board. 

The board was immediately pul to use when it became avail- 
able and solved many microcode bugs in its lirsl weeks of exis- 
tence. After a few weeks, users began lo develop some uncon- 
ventional uses for the board. An interesting unconventional appli- 
cation is lo use the board as a smart single-step facility for the 
MPE operating system to single-step over PCAL instructions, in- 
terrupts, etc. In this mode of operation, the MPE system Debug 
facility is used to freeze Ihe segment in question lo prevent ihe 
operating system from moving Ihe segment. Then the breakpoint 
board is programmed in RANGE mode such that the Iwo break- 
point registers poini lo the start and end of Ihe procedure or 
segment in question. The CONTINUE key of Ihe Model 236 Com- 
puler can ihen be used lo single-step over the segmeni 

One dramalic case of breakpoint board application occurred 
when the microcoders had been chasing a problem for several 
days and had totally forgotten aboul Ihe already programmed 
breakpoinl board inside ihe syslem. Several days later, while 
Ihey were working on anoiher problem, the Model 236 mainte- 
nance panel beeped, indicating a break from the breakpoinl 
board. From there it was a mailer of minutes to find the bug they 
had been looking for lor days 

Mehraban Jam 

Developmenl Engineer 
Computer Systems Division 

the single-step function for the software display mode. 
There is an overhead line that always occurs between 
machine instructions in the main microcode. When a 
single-step at the macromachine level is requested, the CPU 
is allowed to free-run until this line is executed between 

Memory Breakpoint 

Memory breakpoint capability requires that an additional 
hardware module, the SIMB breakpoint board, be installed 
in the Series 37 card cage. I/O is done to this board by the 
maintenance panel by general-purpose I/O routines that 
talk to the SIMB. The user interface code formats these 
calls to the I/O portion of the BASIC code, which in turn 
does I/O over the GPIO board, which causes microcode 
routines to write and read the various registers on the break- 
poinl board. The memory breakpoint is discussed further 
in the box above. 


© Copr. 1949-1998 Hewlett-Packard Co. 

SoftPanel: Virtual Software Debugging Panel 

For software debugging on the HP 3000 Series 37. a spe- 
cial software debug facility, a virtual software debugging 
panel called SoftPanel. is implemented in microcode. 
SoftPanel is not the only software debugging tool available 
in the HP 3000 system. The MPE operating system has its 
help facility (not the same as the HELP command) and there 
is the Debug facility. However, there are times when these 
facilities may be hard to activate and/or cannot run at all. 
SoftPanel is the only debugger on the Series 37 guaranteed 
to be there when needed. It can always execute. 

SoftPanel is a fundamental debugging tool. Through the 
use of its commands, the user can gain low-level informa- 
tion about the system state. This information is vital when 
one is trying to determine the cause of many failures. With- 
out SoftPanel. the user has a significantly lower chance of 
determining what is going on. 

Basic Characteristics 

The Series 37. like other HP 3000s. is a microcoded 
machine. Thus it is really two machines in one. The mac- 
romachine executes the instructions of the HP 3000. The 
micromachine implements the macromachine. SoftPanel 
is designed to debug software at the level of the mac- 
romachine. Other tools exist for dealing with the system 
at the micromachine level, primarily the HP 9000 Model 
236 maintenance panel described above. 

HP field engineers, being the primary customers for 
SoftPanel. had considerable influence on its implementation. 

A major requisite for a debugger is machine state visibil- 
ity. SoftPanel provides this easily because of its microcode 
implementation. Because it is implemented as microcode 
and executes directly on the target machine, visibility of 

different machine states is there for the asking. This in- 
cludes memory, macromachine state, direct 10. and some 
micromachine control cells that directly affect the mac- 

Another major requisite is transparency. The user should 
be able to invoke the debugger, view the desired machine 
state, and return to the software that was interrupted with 
out any undesired effects. This, of course, assumes that the 
machine state was not modified by the user. SoftPanel has 
knowledge of what determines a macromachine state and 
carefully preserves this information. This includes such 
things as I/O system state, memory state, macromachine 
state, and interrupt system state. None of this information 
is altered unless specifically requested by the user. At any 
time, the user can tell SoftPanel to return to the software 
that was interrupted. 

Yet another requisite is remote access. SoftPanel is usable 
from a remote diagnosis center. As the number of systems 
in the field increases, it becomes economically unfeasible 
to service our machines any other way. SoftPanel ac- 
complishes this by making use of the Series 37*s remote 
operator interface. Anything that works on the local console 
will also work through this interface. 

A last major requisite is ease of use. To accomplish this, 
the SoftPanel syntax is closely modeled after Debug's. 
Debug is a very well-known (in the HP 30U0 user commu- 
nity) debugger for the HP 3000. By choosing this syntax, 
we avoided a large portion of the learning curve for many 

SoftPanel Structure 

To facilitate quick design and implementation. SoftPanel 
is partitioned into four major sections: command recog- 
nizer, command parsers, command executors, and special 



^^^^ ^^^^ {^^^) 



Fig. 4. The structure of SoftPanel. 
a microcoded virtual software de- 
bugging panel for the Series 37 


© Copr. 1949-1998 Hewlett-Packard Co. 

functions. Fig. 4 details the structure graphically. 

The command recognizer is responsible for accepting 
user input and determining which command should be 
given control. Included in this activity are prompting, read- 
ing the user response, scanning the first field, looking for 
a valid command, and activating the appropriate command 
parser. If an invalid command is input, an appropriate error 
message is displayed. 

The second major section of SoftPanel consists of the 
command parsers. This software is responsible for scanning 
the rest of the command line for the command's parameters. 
There is one parser for each command. If valid parameters 
are found, a module in the third major part, the executors, 
is activated. 

The command executors actually implement the com- 
mand. Each executor is passed a set number of parameters 
by the corresponding command parser. It performs its ac- 
tion and returns to the command recognizer. What each 
executor does is entirely dependent upon the command. 
Some commands simply take a starting memory address 
and display consecutive locations. Other commands dis- 
play some information and wait for user input. Depending 
upon this input, some portion of the machine state may be 

The last major section deals with special functions. In- 
cluded are memory breakpoints, and the interface to the 

Underlying these major sections are a significant number 
of subroutines. There are subroutines that directly support 
the command recognizer, parsers, and executors, and there 
are primitive subroutines that support base functionality 

Virtual Microcode Memory 

The HP 3000 Series 37 self-test ROMs use an unusual im- 
plementation of a virtual microcode space in the four 128K-bit 
ROMs thai enable the 64-bit CPU to access and run self-test 
functions, boot routines, and diagnostics, simulating a separate 
control processor. This separate control processor, if present, 
would use writable control store (WCS). Since the separate pro- 
cessor is not present, diagnostics, boot code, and other micro- ' 
code can be loaded and run without taking valuable WCS space, 
which is also needed for the mam instruction microcode This 
extra microcode is loaded into WCS only when its functions are i 
needed It is present in ROM on the CPU board and does not 
need to be loaded from disc 

This virtual microcode space is implemented by a routine called 
LoadNxt, which enables a specified program or data file to be 
loaded from ROM into any arbitrary area of WCS so that it can 
be executed or accessed 

This solution minimizes the use of scarce WCS resources, 
which must be shared with HP 3000 instruction set microcode, 
without sacrificing self-test, boot, or diagnostic functionality 


Norm Galassi wrote LoadNxt 

Chris Shaker 
Development Engineer 
Computer Systems Division 

on all levels of the structure. Included are the Following! 
I Field scanner. This routine recognizes the next field in 

the input buffer, determines its type (ASCII string, null. 

or numeric) and returns this information. 

0 Conversion routines. These routines convert between in- 
ternal (binary) and the appropriate external form. This 
external form is either the octal or the hexadecimal ASCII 
equivalent as determined by the current radix. This is 
under user control. 

1 Expression handling. This family of routines deals with 
processing expressions of various forms. Each one starts 
scanning from the current place in the input buffer and 
terminates appropriately. The value of the expression is 
returned to the caller. These expression handlers can 
deal with addition, subtraction, multiplication, indi- 
rection, unary operators, base address modification, and 

a Primitives. These provide buffer manipulation, table 
management, address handlers, basic terminal I/O, and 
connections back to the command recognizer for com- 
mand termination and/or error conditions. 

SoftPanel Commands 

SoftPanel is command-driven. A prompt ISP •) is dis- 
played, the user types the desired command followed by 
its parameters, the command is processed and executed, 
and the cycle is repeated. All activity of SoftPanel is in 
some way caused by the input of a command. This includes 
the special functions (memory breakpoint processing) as 
well as regular functions. 

There are six major groupings of commands: display 
memory, modify memory, input/output, miscellaneous, 
code breakpoints, and memory breakpoints. The command 
syntax is strongly dependent upon the architecture of the 
HP 3000, with its segmented memory system and separa- 
tion of code and data spaces. 

The command-driven approach was chosen for two 
reasons. The first was ease of implementation, and the 
second reason is related to the requirement for remote ac- 
cess. This access is primarily through 1200-baud dial-up 
lines. A full screen debugger becomes extremely obnoxious 
running at this speed. 

Memory Breakpoints 

One very nice feature of SoftPanel is its ability to deal 
with the Series 37 memory breakpoint board (see box, page 
20). This is a hardware tool that allows debugging of ex- 
tremely difficult problems. One such problem is the trash- 
ing of particular memory locations that then cause a system 
crash (bank 0 is a particularly nasty place to trash). The 
memory breakpoint board allows the user to trap writes 
and reads to particular addresses or ranges of addresses. 

SoftPanel supplies an interface for setting this board up 
and handling the results when a trap occurs. 


Harish Joshi implemented the maintenance microcode, 
including the microinterrupt handler, and wrote the low- 
level I/O routines in Model 236 BASIC. Paul Rogers im- 
plemented the special circuitry on the CPU board that was 
required for the maintenance panel. 


©Copr. 1949-1998 Hewlett-Packard Co. 

New Cardiograph Family with ECG 
Analysis Capability 

These three new HP cardiographs, in addition to recording 
traditional ECG waveforms, can perform differing levels of 
measurements and analysis to aid diagnosis of heart 

by Robert H. Banta, Jr., Peter H. Dorward, and Steven A. Scampini 

DURING THE LATTER HALF of the 19th century, it 
was discovered that the contractions of heart mus- 
cles generated electrical signals that could be de- 
tected on the surface of the body. In 1903, a Dutch 
physiologist, Willem Einthoven, was the first to record 
these signals accurately. This was done by placing the sub- 
ject's limbs in buckets of saline solution that were con- 
nected to a string galvanometer (Fig. 1). For his efforts, 
Einlhoven was awarded the Nobel Prize in physiology and 
medicine in 1924. Over the years, a body of knowledge has 
developed by which a physician can deduce the condition 
of the heart from these electrical signals. By examining the 
shape, or morphology, and timing, or rhythm, of these elec- 
trical waveforms, a physician can determine the condition 
of the heart muscles and the conduction mechanism used 
to trigger muscle contractions. 

A variety of instruments for recording these waveforms 
has been developed and the electrocardiogram (ECG) con- 
tinues to play an important role in the diagnosis of heart 
disease. It is estimated that 200,000,000 ECGs are taken 
annually throughout the world. Because of its simplicity, 
noninvasive nature, and widespread acceptance, the elec- 
trocardiogram is used as the first level of screening in the 
detection of heart disease. Further screening involves in- 
creased expense and/or risk lo the patient, requiring such 
methods as stress testing, ultrasound scanning, ambulatory 
(Holler) monitoring, catheterization, and surgery. 

In the 1960s, computers began to find use aiding the 
physician in the diagnosis of the electrocardiogram. Today 
these analysis programs are attaining widespread accep- 
tance as a means to help contain ihe cost of health care. 
These computer systems are expensive, however, and can 
only be justified where large volumes of ECGs are processed. 

Hewlett-Packard's new HP 4760 Cardiograph family (Fig. 
2) combines the analysis capabilities of HP's Model 5600C 
ECG Management System with Ihe technology of the HP 
4700A PageWriter Cardiograph introduced in 1981.' The 
result is a compact and inexpensive tool to aid the physi- 
cian in the diagnosis of heart disease. 

Role as a Diagnostic Tool 

This new family of cardiographs consists of three mem- 
bers: the HP 4760A, the HP 4760AM. and Ihe HP 4760AI. 
All three provide ECG waveforms along with patienl ID 
inlormation (name, sex, age, weight, etc.) in a clear manner 

for quick review by the physician (Fig. 3). The information 
contained on the report can be edited using the instru- 
ment's alphanumeric keyboard and liquid-crystal display. 
The ECG waveforms can then be stored for later retrieval, 
or transmitted over phone lines to another cardiograph or 

Fig. I. Early ECG measurements required putting the sub- 
net's limbs into buckets ot saline solution to make sufficient 
electrical contact lor detecting the electrical activity of the 
heart muscles on a string galvanometer (source of picture 
unknown) The Roman numerals indicate three of the com- 
monly recorded levels They are derived by taking voltage 
differentials referenced to the right leg. That is I = left 
arm - right arm. II - left leg - right arm, and III ■ left leg - left 


© Copr. 1949-1998 Hewlett-Packard Co. 

ECG Storage and Transmission 

In ihe pasl, an ECG was usually transmuted to a remote ECG 
analysis system as It was acquired Poor signal quality, which 
could come from ihe original signal or be induced during trans- 
mission by phone line noise, could not be checked until after- 
wards. If retransmission was required, it was necessary to go 
through the entire process again 

One solution added an optional analog tape recorder to ihe 
cardiograph cart to provide local storage of ECGs This provided 
the flexibility of storing the ECGs as Ihey were acquired, and 
transmission of them as a batch afterwards, but the option was 
costly, bulky, and difficult to manage. 

To provide flexibility and reduce errors in the acquisition and 
transmission of ECGs. the HP 4760A and its predecessor, the 
HP 4750A. incorporate solid-state ECG storage and digital trans- 
mission facilities Local ECG storage is realized by including a 
256K-byte. battery-backed, nonvolatile CMOS RAM capable of 
holding data for up to 40 ECGs Transmission flexibility and integ- 
rity are managed by a custom digital transmission protocol de- 
veloped for the HP 4750A and HP 4760A. 

ECG storage space and telephone connect time are minimized 
by the use of a first-difference encoding algorithm This compres- 
sion algorithm is based on the normal distribution of the firs! 
differences of successive points of an ECG Since most of the 
signal consists of small excursions about Ihe baseline, the original 

1 2-bit data can be greatly compressed by encoding small first 
differences into three- and five-bit codes The algorithm is non- 
distoning, so Ihe original data is faithfully recreated upon decom- 
pression with no loss of accuracy 

An important part of the transmission protocol is its error delect- 
ing and handling capabilities, since the compression algorithm 
is extremely sensitive to error. The lower level of the protocol 
provides blocking, line arbitration, and link integrity besides CRC- 
CCITT-based error detection Data blocks are accompanied by 
CRC (cyclic redundancy check) codes, and any detected errors 
result in retransmission of data If a block cannot be transmitted 
without error after several attempts have been made, the link is 

The upper level of Ihe protocol supports an expandable com- 
mand interpreter lhal allows Ihe transmission of ECGs, analysis 
reports, and ECG measurement information from cart to system, 
cart to cart, and system to cart. For example, by accessing the 
system data base through a local cardiograph, a physician can 
review a patient's previous ECGs while al the patient's bedside 

Charles C. Monroe 
Project Manager 
McMlnnville Division 

to a central computer system (see box above). 
HP 4760AM. The HP 4760AM Cardiograph also performs 
a series of measurements on the ECG waveforms. These 
measurements fall into two major categories: morphology 
and rhythm. (For details about these measurements, see 
article on page 29.) In most cases, the HP 4760AM is able 

to perform these measurements more quickly and accu- 
rately than a human. This eliminates much of the drudgery 
of ECG analysis, allowing the physician to concentrate 
more time on patient care. 

HP 4760AI. The physician's job is made even easier by the 
HP 4760AI Cardiograph, which applies a series of criteria 

Fig. 2. The HP 4760 A family ol 
cardiographs leatures Ihe plotting 
technology olthe earlier HP 4700 'A 
PageWnter Cardiograph with 
stand-alone computer analysis 
techniques based on HP's Model 
5600CECG Management System 
Data can also be transmitted to a 
central system for storage and 
later review 


© Copr. 1949-1998 Hewlett-Packard Co. 

(based on rules similar to those learned by the physician) 
to the ECG measurements, yielding a preliminary interpreta- 
tion of the ECG |Fig. 4). Either an adult or a pediatric criteria 
set can be used depending on the patient's age. In addition 
to reducing the physician's work load, interpretive cardio- 
graphs are being used to generate preliminary interpreta- 
tions in situations where physicians skilled in ECG diag- 
nosis are sometimes not immediately available. 

The interpretation produced by the HP 4760AI has been 
found to be diagnostically correct better than 90% of the 
time." Because the analysis may not be always correct, the 
physician must continue to have the final say as to the 
actual condition of the heart and the resultant care of the 

Design Philosophy 

The primary challenge in the development of the HP 
4760 family was providing the analysis capabilities of ECG 
computer systems in a stand-alone instrument at an afford- 
able cost. The existing technology of HP's PageWriter Car- 
diograph family seemed an appropriate base from which 
to begin since it contains the necessary cardiograph func- 
tions at a low price. It also offers an X-Y recording mech- 
anism, unlike the traditional galvanometer writing system 
used in many other cardiographs. This recording mecha- 
nism allows the flexibility to generate ECG traces and in- 
terpretive reports in an easily handled format. 

Very early in the design of the HP 4760A. the decision 
was made to use an exact copy of the analysis program 
used in the HP 5600C ECG Management System. This 
greatly reduced the development time, but more important, 
yielded an analysis program that was already clinically 
proven and well accepted. The major obstacle to this effort 

was that the HP 5600C ECG Management System is based 
on an HP 1000 Computer, while the HP 4760A Cardiograph 
is based on a 68000 microprocessor. 

A multistage plan was developed to effect the program's 
translation. At each stage, the accuracy of the translation 
was verified by analyzing ECGs from a common data base 
and comparing the results to those produced on the HP 
5600C. Some minor differences were found in intermediate 
results, which were caused by floating-point precision dif- 
ferences between the two processors. However, none of the 
ECG interpretations showed any differences in the final 

Another design goal of the HP 4760 was to provide an 
easy upgrade path. A port is provided for a plug-in module, 
installable by the user, that can contain application pro- 
grams or criteria sets for the analysis program (Fig. 5). Such 
a module can be used to upgrade an HP 4760AM to provide 
full interpretation. A criteria set in a plug-in module could 
supplement those already in an HP 4760AI, or another 
module could be used to replace a standard criteria set 
with an adjusted version. An application module is more 
open-ended, because it can modify the standard firmware 
or add a new capability. Application modules currently 
available include: 

n HP 4761 1 A Adult Criteria (Version 06). This module can 
be added to existing HP 4760AM Cardiographs to pro- 
vide adult ECG analysis capability. 

= HP 4761 2 A Pediatric Criteria (Version P2). This module 
adds pediatric ECG analysis capability to HP 4760AM 
and HP 4760AI Cardiographs. 

□ HP 47619A ECG Collection (I). This module performs a 
very basic check of the analysis operation and contains 
eight stored ECGs of varying diagnoses. This data can 

72 ■•art if 
130 lb 61 I. 
BP 146/82 

[ mt 13. 

'•• V t (BSD 94 

. an -i 

17 JUII I98S 



HmI.U Pochard 4160(1 Cardiograph 


&»q'ri bv Junca 
Omr 68 Poo 112 
Petumrwn. XO ul rnl n . E3lt«ol »5 





?5 »»/6ec:l cm/ ml 


f- 44400-0000 

~ H 40 


Fig. 3. Example of typical ECG 
record (48% of actual size) taken 
with an HP 4760 A Cardiograph 
Patient information and physi- 
cian's comments can be easily re- 
corded with the waveforms in a tor- 
mat easily filed lor future reference 


© Copr. 1949-1998 Hewlett-Packard Co. 

110 lb 61 In 

□BSD 94 
01 291 
OtC 431 


Doug Cur won 

17 JUN 1985 


hlBim fiBfiiumitm nith aapio RHTHICUU* Bfireflf of l>* 
liftwo »xis 

LVM BY VfltlflS 


-nflWJRHfll CCG- Packard 4760ft Cordloorool. 


R*q*d br Jonaa 
Dp.r 88 Uo. 
PPtlJMlNBR*. KJ m0A nwl*k Edited 

Fig. 4. The HP 4760AI Cardiograph 
can perform a preliminary inter- 
pretation of the ECG data based 
on clinically established data to 
aid the physician. Shown is the in- 
terpretation output tor the ECG 
record shown in Fig. 3 

be used in learning or demonstrating the cardiograph, 
and eliminates the need for a test subject or patient 

The HP 4760AI normally houses 576K bytes of ROM, 
320K bytes of which contains the analysis program. Fully 
configured, the basic HP 4760A can support 1.7 Mbytes of 
ROM and RAM. To protect an investment in masked (cus- 
tom) ROMs, and to provide fixed addresses for application 
programs, all module calls go through jump tables located 
in a pair of F.PROMs (electrically programmable read-only 
memories). If it is necessary to change a software module 
contained in a masked ROM, the updated version is placed 
into an EPROM and the jump table is adjusted to point to 
the new version. 

Operator Interface 

An effective electrocardiograph has to be easy to use. 
One aspect is the design of the control panel. It was felt 
that a properly designed control panel would go a long 
way in making the operation of the HP 4760A self-explana- 
tory. Another aspect is the provision for acquiring high- 
quality, noise-free recordings. When a list is made of the 
functions and parameters that can be selected on the HP 
4760A, it becomes apparent that the operator interface had 
to be well thought out to avoid being overwhelmingly cryptic. 

After considerable discussion, several strategies emerged 
to structure the design. First and foremost, the HP 4760A 
should be easy to use as a basic electrocardiograph so that 
in a possibly confused clinical setting, relatively untrained 
personnel can easily obtain a diagnostic electrocardiogram. 
Second, the values of the parameters that are subject to 
frequent modification should be visible and easily changed. 
Third, the functions that the HP 4760A performs should 
be grouped into two broad categories: basic electrocardio- 
graph and data management. Under data management come 
the functions of storage, transmission, and editing. Fourth, 
many parameters can customize the HP 4760A to a particu- 
lar setting and should be protected; these are typically set 
on receipt of the machine and are never changed thereafter. 

Using these basic guidelines, a design emerged that 
makes extensive use of softkeys. using the HP 4760A's 
liquid-crystal display for labeling (Fig. 6). Dedicated keys 
are carefully limited to only the most frequently used func- 
tions, because it was felt that a vast array of keys would 
intimidate an operator. The customizing parameters are 
hidden behind an unlocking sequence of key presses so 
that they are not wandered into easily during day-to-day 

Careful attention was paid to the color scheme used on 
the keyboard. Keys are prioritized by brightness of color 
and grouped by commonality of color. The less frequently 
used alphanumeric typing keys are assigned low color 

priority so as not to overwhelm the operator looking for 
the START button. 

The result is an interpretive cardiograph with data stor- 
age, transmission, editing, administrative report genera- 
tion, and self-testing capabilities that are straightforward 
to use. yet highly flexible. 

Signal Processing 

The ECG signal is subject to contamination by noise from 
a variety of sources. Three important noise categories are 
ac power line interference (50 or 60 Hz), baseline wander, 
and muscle artifact. 

Power line interference appears as a 50/60-Hz "buzz" on 
the electrocardiogram. Two primary sources are the elec- 
trostatic fields generated by power wiring and the magnetic 
fields generated by devices such as transformers and 
motors. The electrostatic fields produce a common mode 
voltage on the patient relative to ground. This is typically 
not a problem; high common mode rejection is relatively 
easy to achieve. Magnetic fields, however, induce differen- 
tial signals in the loops formed by the lead connections to 
the body. Unfortunately, these 50/60-Hz signals are well 
within the passband (0.05 to 100 Hz) of a diagnostic 

A notch filter is a practical solution if its stop band can 
be made wide enough to allow for normal ac power line 
frequency variations, yet narrow enough to avoid visible 
distortion of the ECG signal. Attempts to implement notch 
filters as conventional analog filters requires relatively 
wide bandwidlhs to accommodate component drift. Such 

Fig. 5. A small slot in the back ol every HP 4 760 A is designed 
to accept any of the existing or future application modules. 


© Copr. 1949-1998 Hewlett-Packard Co. 

Artifact Indication 

Acquiring a noise-free electrocardiogram requires careful 
technique Possibly the most difficult source of noise to control 
is muscle artifact, since it is largely determined by the degree 
to which the patient is relaxea and comfortable In the past the 
operator of a cardiograph could not predict now much muscle 
artifact would contaminate the ECG waveforms. Obtaining a 
"clean" record might require several tries and consume multiple 
sheets of paper The artifact indicator on the HP 4760A Cardio- 
graphs addresses this problem by providing a preview of the 
level of anifact before an ECG recording is started 

Muscle artifact appears on the ECG waveform as a relatively 
low-amplitude, relatively high-trequency signal with random 
amplitude and frequency variations (see Fig. 1) Most of the 
energy m the ECG signal lies below 35 Hz. much of the muscle 
artifact energy lies above 35 Hz This suggests a simple im- 
plementation for detection of artifact a high-pass filter with a 
corner frequency at 35 Hz. followed by a detector, a low-pass 
filter, and a display However, it turns out that the R-wave excur- 
sions generated by the depolarization of the ventricles contain 
significant energy above 35 Hz. The simple system described 
above adequately displays muscle artifact, but is contaminated 
by the R-wave energy passing through the filter This appears 
as a periodic heartbeat deflection 

This problem is solved by replacing the low-pass filter with a 
section consisting of a comparator and an integrator (Fig. 2) 
The rate of change of the output of this section is limited by the 
time constant of the integrator stage and the maximum output 
swing of the comparator These two parameters can be selected 



(a) ! (b) 

Fig. 1. f CG waveforms and HP 4760A artifact indicator dis- 
play for signals (a) without and (b) with significant muscle 

such that the relatively slow changes m the amplitude envelope 
of the muscle artifact pass through the filter while the brief R-wave 
pulses are attenuated and produce minimal deflection 

To enhance the usefulness of the artifact indicator display 
further, a logarithmic compression stage is placed after the output 
low-pass filter The increased dynamic range of the display pro- 
vides leedback m situations where initially the artifact level may 
be very high To a provide a simple bar display for the three 
channels being previewed, the channels are continuously mon- 
itored and the channel wilh the highest level of artifact is dis- 
played The cardiograph s filter and gain settings affect the sig- 
nals sent to the artifact display process Thus, one can preview 
the effect of filter and gain changes before a record is taken. 
The result is a feature implemented in software without additional 
hardware costs that makes low-noise ECG recording easier and 
more economical. 

35-Hz. 4-Poie 

High-Pass Filter 


Channel 2 

Channel 3 





Fig. 2. Signal processing block 
diagram of the HP 4760 As artifact 

filters have a tendency to ring following sharp transitions 
in the ECG waveform. Digitally implemented filters do not 
drift, allowing for very narrow notch filters. In the HP 
4760A, the ac power line notch filter is implemented in 
software running on the internal 68000 microprocessor. 
The final notch width was determined by studying the 
effect of the filter on both actual and simulated ECGs. The 
final filter design very effectively removes power line inter- 
ference and can tolerate expected frequency variations, yet 
does not visibly distort the electrocardiogram. 

Baseline wander is the term used to describe low-fre- 
quency components that appear in the electrocardiogram 
but are not part of the ECG signal. These components typ- 
ically are the result of patient respiration or slow elec- 
trochemical phenomena associated with the electrode-elec- 
trolyte-skin interfaces. Although high-pass filtering will 
remove these components from the signal, the problem has 

been that conventional analog fillers also introduce phase 
distortion, which can seriously distort certain important 
features in the ECG waveform. 

The high-pass filter's cutoff frequency can be increased 
significantly above the 0.05 Hz value recommended by Ihe 
various standards committees without significant degrada- 
tion of the electrocardiogram if no phase distortion is intro- 
duced. Here again, digital filter techniques make the de- 
sired response practical to implement. It is feasible by the 
use of digital memory, in essence, to "reverse" lime and 
"undo" phase distortion introduced by a filter section. 
Such a zero-phase filter (Fig. 7) is implemented in software 
on the 68000 microprocessor. It reduces baseline wander 
without significantly distorting the ECG waveform. 

The electrical signals generated by the activity of the 
skeletal muscles also interfere wilh the ECG signal. These 
signals are referred to as muscle artifact. They are similar 

© Copr. 1949-1998 Hewlett-Packard Co. 


Fig. 6. Operating panel of the HP 
4760 A tamily ot cardiographs. 

in amplitude and frequency to many of the small, high-fre- 
quency components of the ECG. Although a simple low- 
pass filter reduces muscle artifact, it also attenuates desir- 
able high-frequency features. Alternatively, muscle artifact 
can be reduced by having the patient relax. However, the 
patient's state of relaxation may not be apparent to the 
cardiograph operator before a recording is started. The arti- 
fact indicator on the HP 4760A provides an indication of 
the level of artifact being generated by the patient. It allows 
feedback from the operator to the patient; the patient can 
be made more comfortable or reassured before the ECG is 
committed lo paper (see box on page 27). 


The team responsible for the cardiograph design in- 
cluded Doug Brown. John Goodnow, Bob Graves, Charlie 
Monroe, Toby Olsen, Dick Regan, and Greg Vogel, in addi- 
tion to the authors. The translation of the analysis program 
was accomplished by Siobhan Charlesworth, Bob Cohn, 
John Doue, and Dave Sturges. The packaging for the HP 
4760A and its cart, the HP 4721A, were designed by the 
industrial design team of Ray )edrey. Ted Minor, and Pete 
Rhoads. Jeff Corliss was a major contributor to the defini- 
tion of the HP 4760A, while concurrent manufacturing en- 
gineering was ably performed by Jack Lazzaro. The con- 
certed effort of these individuals, and many others in the 
Andover Division, made the development of the HP 4760A 

family of cardiographs possible. 

1. P.H. Dorward, et al, "New Plotting Technology Leads to a New 
Kind ol Cardiograph," Heivleil-Packard Journal, Vol. 32. no. 10, 
October 1981. 

2. M. Hodges, "A Clinical Evaluation of the HP ECG Analysis 
Program: Program Accuracy and Value of Adjustable Criteria," 
Computers in Cardiology, September 1979. 



b(n) y^j b(-n) 






c(n) k _ 


a(n) -►■ — ► d(n) 
h (n)=h(n)-h(-n) Taking the Fourier transform, h [h(n)]=H(e l ") and F [h(-n))=H (e"") 

/•[h(n)] = H(e"')-H(e"')=H(e") 
|H'(e"")| = |H(e'"')|' 

Fig. 7. Block diagram ol zero- 
phase, high-pass filter 


© Copr. 1949-1998 Hewlett-Packard Co. 

Computer-Aided ECG Analysis 

by John C. Doue and Anthony G. Vallance 

COMPUTER-AIDED ECG interpretation got under 
way about 25 years ago with the simultaneous de- 
velopment of two separate computer programs — the 
Pipberger program 1 and the U.S. Public Health Service's 
ECAN program.* In those early days when the programs' 
performance was. at best, "fair." and the ECG computer 
system's capabilities were limited, the concept of com- 
puterized ECG interpretation/management had yet to be 
proven. Today, the major ECG analysis programs are con- 
sidered good, and close to 20% of the ECGs taken in the 
U.S.A. have a computer-assisted interpretation. The con- 
cept is now accepted and widespread use is a matter of 
continuing performance improvements and price reduction. 

Hewlett-Packard entered the computerized ECG analysis 
field in 1968 by obtaining both the Pipberger and ECAN 
programs for incorporation into an ECG management com- 
puter system — the Model 5600C. These analysis programs 
went through about seven years of evolutionary improve- 
ments before they were replaced by a totally new HP 
analysis program in 1978. The new HP program was readily 
accepted by the market and new features such as ECG 
Criteria Language (ECL) and user-definable medical criteria 
have increased the general market acceptance of com- 
puterized ECG interpretation."' Since its introduction, the 
program has gone through several revisions in both its pat- 
tern recognition algorithms and its medical knowledge 
base. (For more discussions about Ihe program, see refer- 
ences 4 and 5.) 

ECG Waveform 

What is an ECG waveform, and what do we need to 
measure for analysis? 
The ECG waveform (Fig. 1) has several parts that depict 



Fig. 1. Typical ECG waveform tor three consecutive 
heartbeats The analysis program's assignment is to locate 
each ol the PQRST complexes correctly, and to measure the 
height, the width, and a multitude ol other parameters as 
depicted in Fig. 2. 

the action of the heart cycle. The principal parts are the P, 
QRS. and T waveforms, which together are called a com- 
plex. Irregularities in the shape (morphology) of the PQRST 
complex indicate heart muscle abnormalities. Irregularities 
in Ihe timing of the waveforms (rhythm), either within one 
complex or between several complexes, indicate nerve con- 
duction abnormalities. Therefore, the shape and regularity 
of the ECG waveform are both necessary in making a proper 
diagnosis of the condition of Ihe heart. Normal variations 
and medically important ECG conditions make the practice 
of diagnostic ECG interpretation a complex and hard- 
learned profession. 

The analysis program's assignment is to locate each of 
the PQRST complexes correctly and to measure the height, 
the width, and a multitude of other parameters as depicted 
in Fig. 2. 

Program Structure 

The HP ECG analysis program is composed of several 

(continueo on page 3') 

^^"^QR S AH e A T A H g 

Fig. 2. Measured ECG parameters tor ECG shown in Fig 1. 


© Copr. 1949-1998 Hewlett-Packard Co. 

ECG Criteria Language 

Hewlett-Packard has developed a medically oriented com- 
puter language for the definition of electrocardiographic criteria 
Called ECG Criteria Language, or ECL. the primary objective is 
to allow criteria definition m familiar electrocardiographic terms 
by physicians with no knowledge of computer programming 
Basically, it provides a mechanism through which ECG criteria 
may be expressed in a form readable by both a cardiologist and 
a computer By referring to electrocardiography textbooks and 
by communicating with a wide cross section of users, language 
constructs that are consistently used to describe ECG criteria 
have been chosen to form the foundation of ECL. 


At the highest level, criteria expressed in ECL are broken into 
medically significant categories that are analogous to chapters 
of an electrocardiography textbook Category headings take the 





Within each category is a series of sentences m which ihe 
actual criteria are expressed. These sentences allow the program 
to print a diagnostic statement when the criteria are met, to 
SUPPRESS a statement in the presence of a higher-priority diag- 
nosis, GOTO another point in the program, or perform calculations 
and SET the result to a special variable for use later in the pro- 
gram. The PRINT sentence has the form; 

PRINT <diagnostic statement - IF < medical criteria>; 

For example, the following statement causes the inferior infarc- 
tion statement to be generated on the report if the criteria are met: 



where IMMO is Ihe diagnostic code corresponding to the state- 
ment in quotation marks and AB stands for an abnormal finding 

It is important to remember that whereas a cardiologist reading 
an ECG can immediately discount many classes of diagnoses, 
a computer program must check them all sequentially Within a 
category, criteria essentially become more and more restrictive 
Consequently, in ECL. criteria met for any given statement au- 
tomatically suppress any previous statements that would have 
been printed from the category. For complete control, however, 
the criteria writer must be able to suppress statements from other 
categories selectively and to branch over categories or sections 
of criteria inconsistent with the current criteria. These are ex- 
pressed in the sentences: 

SUPPRESS ' list ot statements> IF <medical cn!ena> ; 
GOTO < criteria label> IF < medical criteria> ; 

For example, the sentence: 


would cause suppression of any abnormal axis statement in the 
presence of a left anterior fascicular block, a left posterior fascicu- 
lar block, a bifascicular block, a WPW (Wolff-Parkinson-White 
syndrome), or a complete left bundle branch block, 

The following could appear at the beginning of Ihe RVH cate- 


which would cause the program to skip to the top of the next 
category— left atrial enlargement— if the QRS duration is greater 
than 120 ms, thereby disabling the entire RVH category. 

Finally, user-defined variables can be assigned values, 
perhaps derived from mathematical combinations of measure- 
ments, by the sentence: 

SET < variable > = <expression> IF <medical crileria>; 

In the sentence: 


a wide ventricular activation time parameter for use in LVH criteria 
is set if VAT is greater than 50 ms in either V5 or V6 in the absence 
of any ventricular conduction delay diagnoses. 


Medical criteria are expressed in terms of enhanced logical 
expressions that are both concise and unambiguous. The sen- 

Positive P waves greater than 0 25 mV in two of leads 1 , 2, 
or aVR 

is written in ECL as; 


where the relation " . . greater than ." is abbreviated to GT 
and the lead coincidence requirements are specified in both 
English and ECL by nearly identical phrases starting with Ihe 
word in. The parentheses allow the lead coincidence require- 
ments lo be applied lo more than one criterion. 

In everyday communication of ECG criteria, knowledge of the 
basic form of an ECG complex is implied. For example, when a 
cardiologist says: 

O amplitude is greater lhan 0 1 mV . , ." 

it is assumed that the Q wave is negative. In ECL this would be 
written as 

.Q. AMPLITUDE GT 0.1 . . 

and It means exactly what the cardiologist expects. 

If the sign of the amplitude is relevant, then this can be tested 
explicitly in ECL. For example: 


© Copr. 1949-1998 Hewlett-Packard Co. 


Other Criteria 

In addition to ECG measurements- mere is other information 
available to the ECL crrtena wnter For example, indexes of the 
quality o' data specifying various types and levels of noise such 
as missing leads muscle tremor, ac interference etc can oe 
used to indicate thai the interpretation may have Been com- 
promised because important information was missing Also, pa- 
tient information entered via the cardiograph such as age. sex. 
body build, medication, previous diagnosis (e.g.. CAD. hyperten- 
sion), blood pressure, race, etc can be used In the analysis 
where appropriate. 

Self Documentation 

To make the final criteria documentation as readable as pos- 

sible, the language is free from formatting restnctions The com- 
piler provides extensive error checking and reporting, and option- 
ally provides the following final criteria documentation 

■ Table of contents 

■ The declaration block, which consists of a list of user-declared 
variables. RX names and codes, previous DX names and 
codes, and modifiers 

■ Diagnostic critena by category 

■ A list of statements with text formatted as it would appear in 
the diagnostic reports 

■ Cross-reference information 

ECL has been used extensively by HP 56O0C ECG Manage- 
ment System users to optimize the HP Analysis Program for their 
particular ECG reading style. In addition, our research-oriented 
users have made use ot ECL to communicate new criteria to 
other users for evaluation and comment 

main modules (Fig. 3). The Quality Monitor examines the 
incoming data for various types of noise contamination 
and passes this information back to the operator for correc- 
tive action and into the Data Conditioning module. This 
module applies a 50- or 60-Hz notch filter to the data if 
any ac noise is detected. All ac noise is thus eliminated 
before the data is sent to the Pattern Recognition module, 
which adaptively filters each P. QRS. ST. and T region to 
produce a comprehensive set of measurements for each 
region. These measurements are then polled and passed to 
the Criteria Module. This module contains the medical 
criteria — such as those found in electrocardiography text- 
books — used for making the diagnosis. On an HP 5600C 
ECG Management System, additional capabilities include 
a diagnosis that includes a comparison with the previous 
ECG and modification of the criteria by the user. 

Waveform Boundary Indicator 

The most crucial decisions for the Pattern Recognition 
module are to identify all the QRS waveforms correctly 
and to allocate an accurate search region for all remaining 
component waveforms, (i.e.. P and ST-T waveforms). A 
search window should be as narrow as possible and yet 
wide enough to contain the earliest onset and latest portion 
of a particular simultaneous three-channel waveform. En- 
hancing the features of the signal from those of noise is 
critical to reduce the possibilities o( mislabeling waveform 
components in the early stages. When searching for a QRS 
waveform, a tall T wave is just as undesirable as noise 
contamination. Therefore, the goal is to transform the ECG 
signal into different forms SO that there is maximum separa- 
tion between the P, QRS, and T waves and noise. The 
transformed signal is called the waveform boundary indi- 
cator (WBI) and it is derived from the simultaneous three- 

channel ECG signal. The WBI is based on the combined 
magnitudes of the first and second derivatives as follows: 

WBI(k) = C, S 

1 = 1 

if;(k)i+ c 2 £ 



where k refers to the kth sampled data point, and C, and 
C-t are constants. The subscript i refers to the ECG signal 
from channel i. In other words, the WBI is a weighted 
average of the speed and acceleration of the ECG signal 
over the three channels. The equations for the first and 
second derivatives are: 

f'(k) = f(k + l) - f(k-l) 

f"(k) = f(k + 2) - 2f(k) + f(k-2) 


The WBI works well in detecting QRS waveforms and 
in discriminating against T and P waves. However, it tends 
to be narrower than the simultaneous three-channel QRS 
complex. Furthermore, it does not significantly enhance 
the T and P waves over the noise. To correct both of these 
problems, another version of the WBI, called WBIF, is 
created fro m the same data after digital filtering. The fil- 
tered data f( n ) is obtained by convolving the raw ECG 
data f(n) with the impulse response h(n). 

f(n) = h*f = Jf h(k)f(n-k) 

k= IN l| 


The impulse response h(n) is given by the triangular 
waveform shown in Fig. 4. 








IB ArUntlve 


Optional on Optional User Criteria 

ECG System Modifications on ECG System Fig. 3. Analysis program structure 


© Copr. 1949-1998 Hewlett-Packard Co. 


-(N-1) -2-10 1 2 N-1 n 

Fig. 4. Impulse response to be convolved with rawECG data 

Fig. 5 shows a typical set of three-channel ECG wave- 
forms and the associated WBI and WBIF. Note that the QRS 
complex can be easily extracted from a "high" condition 
in both the WBI and the WBIF. After identifying and then 
excluding the QRS regions, the remaining "high" regions 
are the T and P waves. While the WBIs identify the initial 
search regions, all the measurement parameters are derived 
from the original raw data. 

Morphology Measurements 

Within the search regions established by the WBIs, each 
waveform component is processed to establish its: 
" Onset and endpoints 

■ Amplitudes, durations, shapes, areas, etc. 

Delta waves, notches, slurs, and pacemaker spikes. 

The QRS complexes are analyzed first, followed by the 
ST-T waves, and finally the P waves. Since the QRS 
waveforms are the most prominent and therefore the ones 
that can be most confidently measured, they are analyzed 
first and their exact onsets and endpoints are used to im- 
prove the performance of the P and ST-T measurements. 

The exact onset and endpoints of P and T waves are 
located through the analysis of four sets of data within the 
predetermined WBI region. These data sets include (see 
Fig. 6): 

The raw ECG data f(x) 

The data smoothed by adaptive filtering 

The first difference function f'(x) 

■ The second difference function f"(x). 

By using the properties of the maxima and minima of 
f'(x) and f"(x), approximate departure points of the ECG 
waveform from the baseline can be located. These are then 
used in conjunction with the empirical threshold to deter- 
mine the exact onset and endpoints. 

Adaptive Filtering. Each waveform component such as a 
P, QRS. ST, or T wave is examined and filtered indepen- 
dently for noise contamination before it is measured. The 
measured amount of noise is the waveform's "signature." 
A signature is defined in terms of the critical points such 
as maxima, minima, and zero crossings of the data, f'(x), 
and f"(x). The data is iteratively smoothed until the signa- 
ture is within an acceptable level before analysis is per- 
formed. The filter uses a quadratic polynomial least- 
squares technique to calculate the smoothed data, 
smoothed f'(x), and smoothed f"(x). The amount of smooth- 
ing is specified by the number of data points used to fit 
the curve. 

Rhythm Analysis. After all beats are analyzed and mea- 

sured, they are classified into groups based on RR interval. 
QRS duration, PR interval, and pacemaker spike (present 
or absent). For each group, mean values are calculated for 
the RR, PR. QRS, and QT regions, etc. If more than one 
group exists, a selection process chooses a group that rep- 
resents the intrinsic rhythm. Beats in this group will be 
used for contour measurements while beats in all other 
groups originating from rhythm disturbances are excluded. 
Measurement Matrix. At this point in the analysis, each 
of the many P-QRS-T complexes in each of the twelve leads 
has been measured in detail. To apply clinical diagnostic 
criteria, twelve representative subsets of measurements, 
one for each of the twelve leads, are polled from the larger 
set. The measurements for the many complexes are reduced 
to a subset by means of a series of confidence checks and 
weighted averages. Complexes originating from rhythm ab- 
normalities are not included in these averages. 

Diagnostic Criteria 

The last module of the analysis program contains all the 







Fig. 5. Typical set ol three-channel E CG waveforms and their 
associated WBI and WBIF. 


©Copr. 1949-1998 Hewlett-Packard Co. 

15 - 


(a) +. 


• MM 

/. M.' 
M* ••• 

0567 0617 

0647 0677 



0567 0617 0647 0677 

• •• 

0567 0617 • 0647* 0677 

medical criteria for making the interpretation. It is the med- 
ical knowledge base. It "sees" the ECG by means of all the 
previous analysis modules. What it sees is the measurement 
matrix. The criteria module is written in a cardiologist- 
readable language called ECG Criteria Language, or ECL 
(see box on page 30 and reference 6). More than just a 
language. ECL is an entire programming environment that 
allows the clinical user to modify, enhance, and optimize 
the criteria on an ECG management system. The criteria 
program is similar to an electrocardiography textbook. Each 
major abnormality category is a separate category in the 
criteria. For example, there is a category for left ventricular 
hypertrophy, a separate one for right ventricular hyper- 
trophy, and yet another one for inferior infarct. Within 
each category are the rules for diagnosing the various gra- 
dations of a particular abnormality. Similar to medical texts, 
there are also rules that specify the relationships between 
diagnoses in different categories. In short, the criteria writ- 
ten in ECL form a powerful tool to carry out clinical criteria 
research or simply to use and understand the analysis pro- 
gram's medical logic. 


t. H.V. Pipberger, "Use of Computers in Electrocardiogram In- 
terpretation."' Circulation Research. Vol. 25. 1962, p. 555. 

2. C.A. Caceres, et al, "Computer Extraction of Electrocardio- 
graphic Parameters." ibid., p. 256. 

3. M. Hodges. "A Clinical Evaluation of the HP ECG Analysis 
Program: Program Accuracy and Value of Adjustable Criteria." 
Computers in Cardiology, September 1U79. 

4. Balda, et al. "The HP Analysis Program." Proceedings. IFfP 
Conference on Trends in Computer-Processed Electrocardiograms. 

5. J.C. Doue. "The T Wave Algorithm of the HP Program." Proceed- 
ings of Engineering Foundation: Computer Interpretation o/ECGs, 

6 ECL Programmers Re/erence Manual. Hewlett-Packard Com- 
pany Medical Products Group Publication #05600-91819. 


Fig. 6. (a) flaw data lor biphase P wave lb) Dala smoothed 
by adaptive filtering (c) First difference function of lb) Id) 
Second difference function of lb). 


© Copr. 1949-1998 Hewlett-Packard Co. 

Pediatric Criteria 

Pediatric ECG interpretation is a special challenge for several 

■ The availability ot pediatric cardiologists is much more limited 
and is restricted mostly to major urban centers. 

,: Pediatric criteria contain a large number of age-dependent 
tables, which causes them to be significantly more difficult to 
remember than adult criteria. 

These difficulties provided the stimulus to extend computer 
interpretation to pediatric ECGs. Coupled with the availability ol 
a standard criteria development tool, ECL (see box on page 30), 
the addition ot a pediatric criteria module to the HP 4760A Car- 
diograph family's ECG analysis program became a reality. 

Rapidly Changing ECG Morphology 

Pediatric ECG criteria are age-dependent, and are therefore 
extremely complex. An example of this complexity is the right 
ventricular dominance al birth, which changes to left ventricular 
dominance with age This differs significantly from a diagnosis 
of right ventricular hypertrophy in an adult. Since the QRS shift 
in the early weeks of life is frequently measured in days, pediatric 
electrocardiographers must memorize, or have available, rather 
detailed tables of QRS voltages, axes, intervals, and other param- 
eters versus age for many leads. An example of these frequently 
consulted charts is shown in Fig. 1 . The chart shows the complex- 
ity ol pediatric criteria. Here, the heart rate versus age is shown. 
Tables such as these are incorporated into the HP 4760A's 
Pediatric Program Module. 

ECL and User Development 

Recognizing the special challenges of pediatric interpretation, 
Dr. Laks and his colleagues at Harbor-UCLA Medical Center set 
out in the mid-1970s to develop a pediatric criteria package for 
the HP ECG analysis program. This effort was greatly facilitated 
by the availability of the ECG Criteria Language, called ECL, as 
a standard development tool on an HP 5600C ECG Management 
System. ECL is a high-level computer language that bridges the 
gap between the programmer and the cardiologist. ECL, unlike 
other computer languages such as Fortran, allows the physician 
lo read the computer criteria directly, facilitating criteria develop- 
ment and enhancement. As a result, the translation of the large 
tables of pediatric ECG values and the development of unique 
pediatric terminology were vastly simplified. 

After the pediatric criteria were successfully developed and 
extensively tested at Harbor-UCLA, the data was submitted to 
HP for evaluation. In addition to examining the criteria from a 
technical viewpoint for incorporating into the ECG analysis pro- 
gram, HP also enlisted the help of Dr Walter Gamble at Children's 
Hospital of Boston to carry out an independent clinical evaluation. 

All Ihe evaluations are now completed and the pediatric 
analysis program is receiving a high degree of acceptance by 
pediatricians. Nevertheless, continuing improvements to the 
pediatric criteria and the adult criteria is an ongoing process, 
which is being propelled by these evaluation results, other user 
critiques, and ECL as a development tool 

0-1 1-3 3-7 7-30 1-3 3-6 6-12 1-3 3-5 5-8 8-12 12-16 

Days Months Years 

Fig. 1. Example ol age-dependent pediatric ECG chart. The dots represent the average heart 
rate versus age. {Derived from percentile charts by A. Davignon, et al, Pediatric Cardiology, 

Vol. 1, 1979/1980. pp. 133-152.) 


© Copr. 1949-1998 Hewlett-Packard Co. 


3f 1985 

4 = HP 3000 Computer System : 

Frank E. La Fetra, Jr. 

2Z3f Skip La Fetra was born in 
"L^ Los Angeles, California and 
studied electrical engineer- 
ing at Stantord University. 
Irom which he received his 
BSEE and MSEE degrees 
in 1976 and 1977 Alter 
I pining HP in 1977, his first 
w ■J assignments as a develop- 
mKm jMl ment engineer involved cir- 
cuit design and analysis, reliability, burn-in. and au- 
tomated lest equipment Later he worked on the HP 
3000 Series 68 and Series 37 Computers and is 
now an R&D project manager Skip is a registered 
professional engineer and a member ot the IEEE . 
and is interested in small, multiuser computer sys- 
tems He and his wile live in Sunnyvale. Calilornia 
He is an avid bicyclist and likes to tinker with per- 
sonal computers 

James H. Holl 

A native Calilornian. Jim 
Holl was born in Palo Alio, 
studied eleclncal engmeer- 
^^^jfcfe mg at the University ol 
^J^H^Hnp Calilornia at Berkeley 
M^k5*f & * B SEE 1966) and the Uni- 

WM0^^^ l *(MSEE1971),andcameto 
^ y ™ HP in 1969 He is an RSD 
' section manager and was 

the section manager responsible lor the HP 3000 
Series 37 Computer He was also a member ol the 
original R&D team that developed the HP 3000 Jim 
lives in Cupertino, Calilornia with his wite and two 
sons, is a youth soccer referee and has been a 
YMCA Indian Guides leader He loves sports, par- 
ticularly ultimate Insbee. managing lo keep up with 
HP teammates who are olten 10 lo 20 years 
younger than he is 

7 = Compute Ar chrtecture : 

Fredenc C. Amerson 
^^^^^^^^^M ArR&DsecK 

f m mi --son has 

W^^^B I .ntnbutedtothedevetop- 
-ent ol both the HP 3000 
m f^^^jt^^M D 1000 Cor : 

^^^^Etr He worked on the pir - 

Wkw tertace lor the original HP 

3000. was a project man- 
liTHBP aget tor tne HP 3000 Series 

64 . and is a section manager for HP 1 000 hardware 
development Rick received a BSEE degiee Irom 
the Georgia Institute of Technology m 1972 and 
came to HP the same year He now lives in Sant3 
Clara, California, is a church pianist, and enioys 
downhill skiing He is also a commercial pilot with 
instrument and multiengme ratings 


: Simulation : 

Paul L Rogers 

Paul Rogers designed the 
CPU board for the HP 3000 
Series 37 Computer and 
contributed to the design ol 
the terminal interlace con- 
troller At HP since 1981. 
his other experience m- 
I eludes work on the 
"» hardware cache lor the HP 
3000 Series 64 Computer 
He is a graduate ol the University of Calilornia at 
Berkeley (BSEE 1 98 1 ) and recenlly completed an 
MSEE degree at San Jose Slate University through 
the HP lellowship program Paul lives m Santa 
Clara. California and has a variety of outside in- 
terests He plays water polo, ultimate Insbee, or 
basketball with other HP employees at lunchlime 
and also enjoys cooking . woodworking, scuba di- 
ving, water skiing, and sailing 

Malcolm E. Woodward 

Born m Ontario. Oregon. 
Woody Woodward served 
in the U S Marine Corps 
belore coming to HP in 
1972 While he was in the 
Marine Corps he super- 
vised the maintenance of 
tactical data systems, and 
in his first HP |Ob he worked 
JJ - as a technician on system 
I/O and on the HP 21 00 Computer Later, as an R&D 
stall member, he contributed lo the development 
of the HP 3000 Series 64 and designed the peripheral 
interlace channel for the HP 3000 Series 37 He is 
currently an R&D protect manager Woody lives in 
Sunnyvale, Calilornia with his son and has one 
other son and two daughters He is an amateur 
radio operator (W6PL T ) and also likes fishing and 
linkering with cars 

Patria G. Alvarez 

- A native ol %sr Jose 

t rutin I in Pat Alvarez 
earned a BSCS degree 
trorr. San Jose State Univer- 
sity in 1983 before coming 
to HP the same year She 
currently works on software 
tor the HP 3000 operating 
system and has also de- 
veloped and maintained 
hardware design tools lor the HP 3000 Series 37 
This fall she will be working on an MS degree in 
computer science at Stanford University Outside 
ol work. Pat enjoys tennis and making handicrafts 
and clothing 

John R. Obermeyer 

John Obermeyer studied 

a electrical engmeenng at 
Northwestern University 
and came to HP in 1981. 
the same year he received 
his BS degree He also 
completed an MS degree m 
computer science at Stan- 
lord University in 1984 He 
I contributed to the design ol 
the terminal interface controller for the HP 3000 
Series 37 Computer and also worked on the diag- 
nostic and utility systems Currently, he is working 
on VLSI chip design. John was bom in Cincinnati, 
Ohio, lives in San Jose. California with his wile, and 
is an advisor and choir director lor youth groups 
in his church His outside interests include painting, 
drawing, woodcarvmg. and volleyball He also col- 
lects fossils, mostly from the Ordovician period 

Greg L. Gilliom 

Currently an R&D project 
manager lor HP 1 000 Com- 
puter products, Greg Gil- 
liom has been with HP 
since 1979 He worked as 
a production engineer on a 
number ol models ol HP 
, 3000 Computers, and later 
| _ ' developed diagnostics and 

ftfl BEkk^N microcode lor the HP 3000 
as an R&D engineer and protect manager He was 
the project manager lor ihe microcode on the HP 
3000 Series 37 Greg was bom in St Charles, Mis- 
souri and graduated Irom ihe University ol Missouri 
wilh a bachelor's degree in electrical engineering 
m 1979 He lives in Campbell. California, is single, 
and has many athletic interests, including sailing, 
wmdsurlmg. W3lersknng, scuba diving, skiing, and 
ultimate Insbee 

17 — Debug Tools: 

Edwin G. Wong 

With HP since 1 979. Ed Wong wrote the diagnostic 
microcode lot Ihe HP 3000 Series 37 and is cur- 
rently working on CMOS VLSI chip design He also 


© Copr. 1949-1998 Hewlett-Packard Co. 

designed an I/O card lor the HP 1000 L-Senes 
Computer and a memory controller lor another 
product A California native. Ed was born in San 
Francisco and earned a BS degree Irom the Univer- 
sity ol California al Sanla Barbara m 1 978. He ex- 
pects to receive an MS degree Irom the University 
ol Santa Clara in 1986 He is a resident ol Sun- 
nyvale, supports the Big Brothers youlh organiza- 
tion, and Isaclive in his church He enjoys windsurf- 
ing, running marathons, and participating in 

William M. Parrlsh 

Bill Parnsh was born in Dal- 
las, Texas and is a graduate 
ol the University ol Califor- 
nia at Santa Barbara (BS 
1973). At HP since 1 974, he 
. has contributed to the de- 
velopment of both the 
J Series 64 and Series 37 HP 
, 3000 Computers and is 
presently investigating Ihe 
field supporlability ol future products. He is a 
member ol both the IEEE and the ACM Bill and his 
wile live in Meadow Vista, Calilornia and enjoy tak- 
ing ballet lessons together His other interests in- 
clude photography, travel, and playing the piano 
and organ 

Eric B. Decker 

At HP since 1980, Eric 
Decker has written micro- 
I code lor the HP 3000 Series 
37, 64, and 68 Computers 
He also contributed to the 
development of the termi- 
nal controller lor the Series 
64 and 68 and to the de- 
velopment of Ihe HP 75C 
I Handheld Computer He is 
interested in distributed systems, computer ar- 
chitecture, and the societal impact of computers. 
He has attended Case Institute ol Technology, 
Iowa State University. Stanford University, and 
Calilornia Slate University at Chico. Eric lives with 
his companion and two children in Scotls Valley. 
California He says he likes t'ai chi ch'uan, intellec- 
tual pursuits, and "yard destruction " 

23 = Cardiograph Family: 

Peter H. Dorward 

I At HP's Andover Division 
since 1 975, Peter Dorward 
I was project manager lor 
Ihe HP 4750A and HP 
4760A cardiographs. He 
was also a project leader 
I for electronics on the HP 
4700A Cardiograph and 
I developed software lor the 
I HP 5600C ECG Manage- 
ment System. Peler was bom in Lancaster, 
Pennsylvania and received an AB degree from 
Dartmouth College in 1973 and a Master ol En- 
gineering degree Irom the Thayer School ol En- 
gineering in 1975 He lives m Harvard. Mas- 
sachusetts with his wife and daughter and enpys 
Softball and skiing He is also renovating a 100- 
year-old Victorian farmhouse, raises chickens, and 
grows Iruil trees and Christmas trees. 

Steven A. Scampinl 

| Born in Bristol, Connec- 
ticut. Steve Scampmi was 
iducated at Rensselaer 
Polytechnic Institute (BSEE 
1 972) and at the California 
nstitule of Technology 
|(MSEE 1973) He worked 
on undersea eleclronics al 
Bell Laboratories, then 
I came to HP in 1976 At HP 
he has contributed to Ihe development of Ihe HP 
4700A, Ihe HP 4750A, and the HP 4760A cardio- 
graphs. He was also Ihe author of an HP Journal 
article on Ihe HP 4700A Steve lives in Reading, 
Massachusetls and likes photography, running, 
and cross-counlry skiing 

Robert H. Banta, Jr. 


At HP since 1980, Bob 
Banta was responsible lor 
ihe integrated tape backup 
and HP-IB interface for the 
HP 7908, HP 79 11, and HP 
7912 disc products He 
was one of the developers 
ol the HP 4750A Cardio- 
graph and was the software 
project leader on (he HP 

4760A Cardiograph Bob was born in Neptune, 
New Jersey and received his BS degree from Duke 
University in 1980 Now a resident of North An- 
dover. Massachusetts, he enjoys bicycling, hiking, 
and soaring 


Anthony G. Vallance 

I Tony Vallance was born in 
lAmersham. England and 
I studied at Woolwich 
I Polytechnic (BS 1963) and 
Northeastern University 
(MSEE 1972). At HP since 
1 974, he is a section man- 
• ager at Ihe Waltham Divi- 
sion and was also a section 
manager at the Andover Di- 
vision. In his earlier assignments he was proiect 
manager for the HP 5600C ECG Management Sys- 
tem and project manager lor the system and test 
software for the HP 77020A ultrasound imaging 
system. He has published several technical papers 
and is a member of the IEE and ACM. Tony lives 
with his wife and two sons in Westlord, Massachu- 
setls and is interested in sailing and astronomy 

John C. Doue 

| John Doue was born in 
China and educated in the 
U.S. He attended the Uni- 
versity of California al 
Berkeley, receiving a BSEE 
I degree in 1967 and an 
I MSCS degree in 1968. 
After working as a software 
engineer at two other elec- 
tronics companies, he 
joined HP in 1 972. He has made a number ol con- 
tributions to the development ol cardiograph prod- 
ucts and is presently a project leader lor the 
analysis program lor Ihe products. He has pub- 
lished papers in conference proceedings, is a 
member of the Amencan Heart Association, and is 
interested in Ihe application ol artificial intelligence 
lo electrocardiograph analysis John lives with his 
wile in Manchester. Massachusetts. They de- 
signed and built an A-frame cabin, all with hand 
tools, in the Maine woods 



September 1985 Volume 36 • Number 9 

Technical Information from the Laboratories of 
Hewlett-Packard Company 

Hewlett-Packard Company 3000 Hanover Street 
Palo Alto Calilornia 9430a US A 
Hewlett-Packard Central Mailing Department 
PO Box 529 Slartbaan 16 
1180 AM Amstelveen. The Netherlands 
Vokogawa-Mewiell-Packard Lid 3uginami-Ku Tokyo 168 Japan 
Hewlett-Packard (Canada) Ltd 
6877 Goreway Dirvo. Mtssissauga Ontario L4V 1M8 ( 

Bulk Rate 
U.S. Postage 







LAUREL ML) 20707 



©Copr. 1949-1998 Hewlett-Packard Co.