I wrote:
> The SX-Key has been advertised as supporting non-intrusive debugging.
> Apparently they aren't quite there yet.  Analysis of the code that the
> debugger installs suggests that it is used to examine and modify register
> status, so it is probably a workaround for bugs in the silicon.

Andy Kunz <mtdesign@FAST.NET> replied:
> Wouldn't they just use a JTAG port that the FPGA core provides?

What FPGA?  What JTAG port?

Even if they had a JTAG port, it wouldn't be useful for reading the register
file; having a JTAG scan path for the entire register file would use a huge
amount of silicon, and probably significantly reduce the speed of the part.

Anyhow, in my experience the JTAG port is often the buggiest part of new
chips.  Apparently no one bothers to simulate the JTAG port very much before
they tape out.

I have no objection to the debugger needing to run code on the target CPU
in order to dump and restore state, provided that it doesn't use up much of
my precious program memory space (preferrably none at all).  The rev D SX-Key
with rev 0.5 host software uses up 5.9 % of the user program memory.

There are several other ways such a thing could be implemented:

1)  Microcode.  Example, Motorola BDM on CPU32 and CPU16.  Probably not
    viable for a part like the Scenix SX, because it probably isn't
    microcoded.

2)  The debugger could feed individual instructions to the CPU core,
    one at a time.  The instructions would thus not consume any program
    memory.  This technique has been used on many machines, at least as far
    back as the early minicomputer days.  A more recent example would be
    the front panel design of the IMSAI 8080 microcomputer (a much-improved
    Altair 8800 clone).  The Microchip PIC is reportedly capable of this
    in a special test mode (with Vpp applied).

3)  The chip could have a separate instruction memory space for debug
    support, which could contain either ROM or RAM.  This technique has
    also been used on many machines, including the Intersil/Harris 6100
    microprocssor (an implementation of the PDP-8 architecture), and the
    System Management Mode (SMM) on many x86 chips.  Note that if the
    special debug memory space is implemented in ROM, this option isn't
    really much different from #1, microcode.

4)  The CPU core could be designed to support a larger instruction address
    space, such that debug support software could be included in ROM in the
    normal address space without reducing the amount of user-available
    EPROM (or Flash).  This is common on larger 8-bit microcontrollers,
    such as the 68HC05 and 68HC11.

I suspect that Scenix must have implemented one of these techniques in the
SX, but I have no idea which one.  In any case, it apparently isn't fully
functional, hence the way the current SX-Key has to steal some user memory.

Cheers,
Eric