From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: "Marko Mlinar" Cc: "Andrew Cagney" , , "Damjan Lampret" , , "Johan Rydberg" Subject: Re: gdb port to or1k Date: Mon, 30 Apr 2001 10:44:00 -0000 Message-id: <5md79u9t9p.fsf@jtc.redback.com> References: <00a501c0ce7d$1fa4c5e0$bb4902c1@Javor> <5mhezbmi6i.fsf@jtc.redback.com> <004b01c0cee8$5617aaa0$e54902c1@Javor> <3AE9CE96.1E5168A6@cygnus.com> <00a401c0cfa9$88b108a0$dc4902c1@Javor> X-SW-Source: 2001-04/msg00232.html >>>>> "Marko" == Marko Mlinar writes: Marko> I've seen JTAG driver or BDM driver. I am aware that JTAG Marko> driver is very slow. We are hoping we can get troughput of Marko> 75kB/sec (with some extra logic), and 15kB/sec without any Marko> logic. Do you think that is enough? I have found that latency tends to matter a great deal more in a typical debugging session than bandwidth. For example, think of stepping a single line of code. The debugger determines the the range of code represented by the line, and then issues a step instruction command. Then it waits until the target responds with a exception or trap. The debugger then must fetch the the program counter to determine whether the step has taken the PC out of range. If not it repeats the processes. As you can see, the commands and responses themselves aren't too long. But if there is significiant communications overhead, it adds up fast. And that is all with relatively high level commands like "step insn". If instead you must fetch the processor control word, or in a trace mode bit, and the store it; or if you fetch the word at the memory location after the PC and then store a trap/breakpoint instruction; it gets that much worse. Even with GDB's remote protocol which had relatively high level commands, I recently added a command for "step over range" which would single step until the PC goes outside the address range specified in the command. I did this just to improve the interactive performance of GDB. Where bandwith matters, is bulk transfers. This usually occurs when fetching or storing the whole register set, and when downloading code. I don't know enough about your interface and processor whether you will be able to fetch and store single registers, or whether you'll have to do the whole set. In most cases, GDB only needs the PC and stack and frame pointers, after a trap to determine "where it is". It's user commands after that which may require more of the registers to be fetched. But even if the whole set has to be fetched or stored, at 75kB/s, a ~512B (32 64-bit int regs, 32 64-bit fp regs, plus a handful of config regs) should be acceptable assuming low communcation overhead. But at 15kB/s, communication overhead will have to be low, since we're already at 1/3 the 0.1 second threshold for interactive response. With a JTAG like interface, I suspect you will want the ability to download code. At 75kB/s, you can download a decent size application in a minute. But for very large applications, I'd probably use the interface to download a secondary boot program that would load the "real" program over a faster medium (ethernet?) --jtc -- J.T. Conklin RedBack Networks