Sign in
Search fpga-cpu
Subscribe to fpga-cpu
fpga-cpu by Keywords
Altera | CISCifying | IDE | ISA | Java | JHDL | JTAG | LBU | MicroBlaze | PAR | PCI | RISC | SoC | Spartan | Transputers | Verilog | VHDL | Virtex | VLIW | WebPack | Xilinx | Xsoc | YARD-1A
Discussion Groups
Discussion Groups | FPGA-CPU | Re: A debugger for xr16 the easy way
This list is for discussion of the design and implementation of field-programmable gate array based processors and integrated systems. It is also for discussion and community support of the XSOC Project (see http://www.fpgacpu.org/xsoc).
Re: A debugger for xr16 the easy way - Ben Franchuk - Jul 25 2:10:00 2001
|
Mike Butts wrote: > > Gee, it sure would be cool to have a gdb stub in xr16 machine > code in a ROM. I've written a simple serial port in JHDL > or Verilog, which I'll cheerfully share. Anybody game to do a > little coding and try this out? Why not just put in serial debugging microcode in like some versions of the PDP11. Just what is being debugged here - FPGA hardware, FPGA microcode (if any) or user program? Ben. Ps. On my cpu on reset a bootstrap loader is run from the serial input. This way all I need for a external parts is memory and a buffer for serial lines from the FPGA. -- "We do not inherit our time on this planet from our parents... We borrow it from our children." "Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk Now with schematics. |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
A debugger for xr16 the easy way - Mike Butts - Jul 25 9:54:00 2001
|
A gdb debugging stub allows gdb to work on a processor through a serial line. This article shows how simple it is. http://www.redhat.com/devnet/articles/embedrem.htm Gee, it sure would be cool to have a gdb stub in xr16 machine code in a ROM. I've written a simple serial port in JHDL or Verilog, which I'll cheerfully share. Anybody game to do a little coding and try this out? --Mike |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: A debugger for xr16 the easy way - Veronica Merryfield - Jul 25 17:43:00 2001
|
Ben >FPGA microcode (if any) or user program? I assume Mike was talking debuging the app code, but... Mike, the GDB stub is only a small part of the story. For GDB to be a complete debug solution GDB needs other information. At the very minimum it must be able to map program counter values to source lines, something contained in debug format sections in the binarys. This information is generated by the compiler and passed through each stage from there. LCC cound be made to emit such information leaaving it in the asm file or producing a separate file. Such files need to be correllated with the placement details such as a map file. Then there is the format of such data. Recent GCC versions use DWARF, old versions use COF. If you then want disassembled source to view, GDB needs that info as well. And, if you want breakpoint and single step, the code must be running in RAM so that the code can be changed in place to invoke a software interrupt. Although the stub work is not that difficult, the implications on an xr16 type target are not that simple to solve. Whilst on the subject I have been wondering if there might be an easier route to app debug. A lot of modern target debug solutions use JTAG, a boundry scan technique - must be plenty of stuff on the web. I was wondering if by placing a small amount of extra gates in a design it would be possible to do something similar. With JTAG, something like the ARM use a debug macro cell that takes it commands and delivers the response using JTAG so it acts like a serial commanded module. JTAG is also used to drive the address buss and read/write the data lines. With this combination, JTAG debuggers can stop the core and take control and this is used for downloading images, reading back RAM content etc. The macro cell can stop/start the core, read registers etc. I would think with some carefull thought, minimumal debug support could be put in a core, even if it needed supporting software, a serial command and response register and something to stop/start the core plus software read/write access to the core under controlled conditions perhaps? Just a thought. PS Incidently, I have just come accros a company that do a tool set that takes a model view of a processor (register set, instruction set definitions) and produces the RTL and the targeted tool chain (Compiler etc) for it. Still awaiting details. I have asked for an education version :) Well I can try! Veronica |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: A debugger for xr16 the easy way - Author Unknown - Jul 26 9:20:00 2001
|
> PS Incidently, I have just come accros a company that do a tool set > that takes a model view of a processor (register set, instruction > set definitions) and produces the RTL and the targeted tool chain > (Compiler etc) for it. Still awaiting details. Is this from Target Compiler Technologies? http://www.retarget.com/products.html The founders have a paper in the July 2001 issue of the ACM Transactions on Design Automation of Electronic Systems: http://www.acm.org/todaes/V6N3/L279/abstract.html http://www.acm.org/todaes/V6N3/TOC.html The HP Labs Computer Architecture Research group has done similar work for the automatic generation of EPIC/VLIW processors and instruction sets, and their associated compilers and assemblers. (They call their tool set "PICO": Program In, Chip Out) |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )