From e6d9de6465aecf64a53b941bf80830280e95c040 Mon Sep 17 00:00:00 2001
From: Bert Lange
Date: Tue, 2 Aug 2011 09:53:37 +0200
Subject: fix: remove note on not existing JTAG/hardware debugger
---
zpu/docs/zpu_arch.html | 24 ------------------------
1 file changed, 24 deletions(-)
diff --git a/zpu/docs/zpu_arch.html b/zpu/docs/zpu_arch.html
index 8aaa132..448d86c 100644
--- a/zpu/docs/zpu_arch.html
+++ b/zpu/docs/zpu_arch.html
@@ -56,7 +56,6 @@ Several of the links will only work if you have checked out the zpu/zpu tree fro
Miscellaneous
Misc
TODO Stuff that could probably find a better home.
-
-JTAG/hardware debugger for GDB
-The Zylin ZY1000 JTAG debugger supports
-the ZPU. Contact Zylin for pricing and details.
-
-There are two debug modes in which the ZY1000 can operate:
-
-- Classic. Here the ZY1000 controls the CPU and examines the state. The ZY1000 has a built in
-GDB server that GDB talks to.
-
- Small footprint. If there isn't enough space on the device for the ZPU *and* the JTAG
-controller, then the ZY1000 can run the ZPU externally. The JTAG communication channel is
-then used to peek/poke peripherals and inside the FPGA instead of the ZPU there is then
-a JTAG controller that peeks and pokes the peripherals of the ZPU. There are advantages
-and disadvantages of this approach: it may be unfamiliar to embedded developers and
-the timing is different from the "real" ZPU(interrupts are delayed, execution speed
-differse, etc.) On the other hand there are other things
-which are simpler: much more RAM can be available for the ZPU during development,
-better debug consoles(faster), additional peripheral(timers, etc.) is available. This
-approach is somewhat unique to the ZPU as the ZPU is simple enough that it can be
-implemented efficiently in this manner.
-
-
-
Speeding up the ZPU
There are two aspects of speeding up the ZPU: making it perform better
--
cgit v1.1