Path: utzoo!attcan!uunet!ns-mx!iowasp!maverick.ksu.ksu.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: On Chip Emulator
Summary: hardware debug support
Message-ID: <9598@pt.cs.cmu.edu>
Date: 12 Jun 90 04:30:06 GMT
Organization: Carnegie-Mellon University, CS/RI
Lines: 39

There's a nifty new wrinkle in the new Motorola DSP, the 96002.

It contains what Motorola refers to as an on-chip emulator. The
"OnCE" has its own dedicated serial interface, and accepts commands
to set breakpoints, report on internal values, and so on.

This is, of course, the logical end of a long trend.  Once, control
points were brought out to a panel - like the B6700, which had a
lighted push button for every flip flop in the CPU.  Later, control
points were brought out to a minicomputer - like the PDP 11/40 inside
each DecSystem 20.  And now, the control points are brought to a
remotely-controlled part of the same chip.

From what little I know, the OnCE seems fairly powerful:
 - break on data address.
 - trace forward N instructions.
 - capture last five instructions, and current pipeline state.

It might be interesting to discuss what else it should do: perhaps
keep the last few branch-from addresses, which I believe the National
'16 did.

Hardware people go for this stuff, of course.  Software people doing
simple embedded applications should agree.  I submit that a "big"
debugger, with system-related features such as file access, should
never be cast in hardware.  But, perhaps a "big" debugger could profit
from the existance of the "hard" debugger.  Hmmm; how?  Maybe only
from privileged code such as the kernel debugger?

The people doing the Parasight debugger at Encore claimed that they
got better performance by not using ANY hardware features, except
whatever cache support it took to have writable code spaces.  For
instance, they did breakpoints by zapping branch instructions, not
traps, into the target code.  The claim was that they could
completely avoid interrupts and kernel entries, and that this was
always a speed win.  I guess I agree, as long as the users are
"above" i860-ish issues such as pipeline configuration.
-- 
Don		D.C.Lindsay 	leaving CMU .. make me an offer!