At the previous day job, we did VME single-board computers based on PowerPC. The boards booted into our monitor program. Older boards used a custom monitor program; newer boards used a single-user version of Linux built against busybox. Both let the user run scripts, run memory/hardware tests, view and modify memory and CPU and peripheral-device registers. As the monitor program evolved, new features were added: it could enumerate the PCI busses, it could discover SCSI devices and mount filesystems, it had networking support, it could update flash memory. Of course one could then boot into a more full-featured operating system, like VxWorks, Linux or the like.

I believe this is what you're looking for.

Most of these SBCs did not had keyboard/video/mouse interfaces (although some of our VGA boards had USB host controllers). The usual human interface to them is an RS-232 port. One could attach a VT-100 terminal to the SBC's serial port and get to work. When new hardware features were added to the SBCs, the monitor program would need to be updated.

But really -- this isn't any different from using the JTAG debug interface on a Silicon Labs part. In fact, the SiLabs interface is preferable in many ways -- it IS a lot faster (no delay typing over the serial port!) and the GUI presents all of your registers and your memory dumps in a nice window.

You mention, "The JTAG is a serial scheme that transfers, at 100 Mbps, a byte in 80 ns, if that's how fast it goes overall, but how fast is that, as compared with the monitor running in real-time?" I have to ask: what is your user interface into your monitor program? Here's where the JTAG interface (or an ICE) is superior to a monitor debugger: the debug hardware controls the processor. You can set various breakpoints, including address hits, register value hits and memory value hits (if you're coding in C, source-level debuggers let you set breakpoints on C expressions), and then the processor runs full speed -- in real time until hitting a breakpoint. There is no performance penalty and peripherals perform as expected with no variation in timing.

So while I think I know what you're asking for, I question whether you know what you want. ICE mechanisms, even using the old Nohau pods with bondout chips have made onboard debug monitors obsolete. The JTAG interfaces have made the bondout pods obsolete (and good riddance).

Think about this for a moment. Most microcontroller projects use specific peripherals, and a debug monitor program would have to be built for each peripheral configuration. This means maintaining different versions for each product. Another point is why waste valuable ROM space (or FPGA logic!) on a debug monitor that your customers will never use?

Consider, instead, the JTAG debug interface. If you want to specifically test some peripheral, you could load a test program that exercises that peripheral. No need to build these sorts of test hooks into your shipping firmware, either (which saves ROM space).

--a