'SX-Key debuger intrusiveness (was Re: Scenix semin'
> 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 <FAST.NET> replied: mtdesign
> 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
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.
|Eric Smith wrote:
> 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).
Hah! I hope you didn't think you'd get away without explaining this! ;) (On the PIC)
Tjaart van der Walt
| WASP International |
|R&D Engineer : GSM peripheral services development|
|SMS wasp.co.za (160 chars max)| 0832123443
| http://www.wasp.co.za/~tjaart/index.html |
|Voice: +27-(0)11-622-8686 Fax: +27-(0)11-622-8973|
| WGS-84 : 26¡10.52'S 28¡06.19'E |
>> Wouldn't they just use a JTAG port that the FPGA core provides?
>What FPGA? What JTAG port?
Sorry, I forgot to add <SARCASM MODE=ON> notation.
It was an offhanded comment to the various PIC core clones available on the
web as programmable logic implementations.
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
More... (looser matching)
- Last day of these posts
- In 1998
, 1999 only
- New search...