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
Ads
Discussion Groups
See Also
Discussion Groups | FPGA-CPU | Remote Target Debugging
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).
Remote Target Debugging - Anand Gopal Shirahatti - Feb 16 19:24:00 2002
|
Hi, I am trying to Debug my FPGA based Processor.Currently I have memory model Interfaced to it.Where I can store the Instruction sequence which it can run.Display the results on Monitor through a VGA controller. I am not able Fast up the Debugging process.I am planning to Use the Remote Target Debugging Concepts.Where I Would like another Host Computer should communicate with the Target FPGA CPU and Run the Program and Probably collect the Results and Verify it. Has any one attempted anything in this Direction.Any words of Experience shall be apperciated.Other suggestions to fast up the Verifications are also Welcome. Thanks, Regards, Anand. |
|
|
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Remote Target Debugging - Veronica Merryfield - Feb 17 16:41:00 2002
|
Hi Anand I'm not 100% sure I understand what you are specifically asking for, but I will outline a couple of ways of debugging code running on a remote target. 1. Write a simple monitor thsat runs on the target. This code communicates with your host and your host can do the hard work. There is very little a monitor needs to communicate with the host to make it work. Read and write memory will cover a lot, plus go and break. The monitor starts up and prompts the host. The host can use the write command to upload the code. The host can then plant break points by writing a special instruction. Once planted, the host issues the go command. When the break point is hit, the monitor starts running. The first thing it does is to store the registers in a safe place then prompts the host. The host can use the read command to get the registers, can use write to modifiy registers using special forms of address and use write to enable or disable breakpoints etc. The host can reissue the go and the registers are restored and the monitor returns from interrupt. The break command also the host to stop execution and force the monitor to run. All the hard work is done by the host. A simplie text based protocol is used so that the monitor can be driven by a terminal or a fully fledged source level debugger (should you have one!). A full source level debugger is a very interest project and thre are lots of gotchas to watch out for (for intance, what do you do about a breakpoint being put on a conditional branch). 2. You could use JTAG to debug. You need to know about the boundary chain and it has to cover the address, data and control busses and have some mechanism to stop execution. JTAG is then used to read and write memory and in some cases small amounts of code would be writen to memory and then executed but still be in the debugger as helper functions. 3. Some IP could be added to the core in either of the above cases to aid the debugger and some debuggers have a mix of all of this. Take a look at what ARM do for debugging (access by JTAG). Also look at ETM, a real time execution trace mechanism. Also check out Lauterbach and CodeComposer from TI. Both are JTAG based. Sometime back, Motorola had some extra IP with the core to aid debugging but I can't remember the name. I hope some of this helps. If you were after something else, drop me a line. Veronica (I don't work for any of the above companies) -----Original Message----- From: Anand Gopal Shirahatti <> To: <> Date: 17 February 2002 00:24 Subject: [fpga-cpu] Remote Target Debugging > >Hi, > >I am trying to Debug my FPGA based Processor.Currently I have memory model Interfaced to it.Where I can store the Instruction sequence which it can run.Display the results on Monitor through a VGA controller. > >I am not able Fast up the Debugging process.I am planning to Use the Remote Target Debugging Concepts.Where I Would like another Host Computer should communicate with the Target FPGA CPU and Run the Program and Probably collect the Results and Verify it. > >Has any one attempted anything in this Direction.Any words of Experience shall be apperciated.Other suggestions to fast up the Verifications are also Welcome. > >Thanks, > >Regards, >Anand. >To post a message, send it to: >To unsubscribe, send a blank message to: |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Remote Target Debugging - Veronica Merryfield - Feb 17 16:43:00 2002
|
PS You could lookj at GDB and GDBstub. The stub runs on the target, GDB runs on the host. -----Original Message----- From: Anand Gopal Shirahatti <> To: <> Date: 17 February 2002 00:24 Subject: [fpga-cpu] Remote Target Debugging > >Hi, > >I am trying to Debug my FPGA based Processor.Currently I have memory model Interfaced to it.Where I can store the Instruction sequence which it can run.Display the results on Monitor through a VGA controller. > >I am not able Fast up the Debugging process.I am planning to Use the Remote Target Debugging Concepts.Where I Would like another Host Computer should communicate with the Target FPGA CPU and Run the Program and Probably collect the Results and Verify it. > >Has any one attempted anything in this Direction.Any words of Experience shall be apperciated.Other suggestions to fast up the Verifications are also Welcome. > >Thanks, > >Regards, >Anand. >To post a message, send it to: >To unsubscribe, send a blank message to: |
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Remote Target Debugging - Anand Gopal Shirahatti - Feb 19 7:47:00 2002
|
Hi Veronica, Thanks for the Information. Infact I have worked on the Soft Scope Remote Target Debugger.But I am specifically Looking if there are any very primitive Custom Implementation of these concepts, that if any one has tryed out. Now the Problem is that we have Developed the Custom CISC in the FPGA. So if we opt for one of these Standard solutions,then tho it may not be a probelm from the Host software. But we will not get the Monitor software that will Boot up on the Target system.Since it is Custom in our case. So I am Looking for the Primitive Implementations of it. Which we should be able to Develop on Our Own. Regards, Anand. On Mon, 18 Feb 2002 Veronica Merryfield wrote : > Hi Anand > > I'm not 100% sure I understand what you are > specifically asking for, but I > will outline a couple of ways of debugging code running > on a remote target. > > 1. Write a simple monitor thsat runs on the target. > This code communicates > with your host and your host can do the hard work. > There is very little a > monitor needs to communicate with the host to make it > work. Read and write > memory will cover a lot, plus go and break. > The monitor starts up and prompts the host. The host > can use the write > command to upload the code. The host can then plant > break points by writing > a special instruction. Once planted, the host issues > the go command. When > the break point is hit, the monitor starts running. The > first thing it does > is to store the registers in a safe place then prompts > the host. The host > can use the read command to get the registers, can use > write to modifiy > registers using special forms of address and use write > to enable or disable > breakpoints etc. The host can reissue the go and the > registers are restored > and the monitor returns from interrupt. The break > command also the host to > stop execution and force the monitor to run. All the > hard work is done by > the host. A simplie text based protocol is used so that > the monitor can be > driven by a terminal or a fully fledged source level > debugger (should you > have one!). A full source level debugger is a very > interest project and thre > are lots of gotchas to watch out for (for intance, what > do you do about a > breakpoint being put on a conditional branch). > > 2. You could use JTAG to debug. You need to know about > the boundary chain > and it has to cover the address, data and control > busses and have some > mechanism to stop execution. JTAG is then used to read > and write memory and > in some cases small amounts of code would be writen to > memory and then > executed but still be in the debugger as helper > functions. > > 3. Some IP could be added to the core in either of the > above cases to aid > the debugger and some debuggers have a mix of all of > this. > > Take a look at what ARM do for debugging (access by > JTAG). Also look at ETM, > a real time execution trace mechanism. > > Also check out Lauterbach and CodeComposer from TI. > Both are JTAG based. > > Sometime back, Motorola had some extra IP with the core > to aid debugging but > I can't remember the name. > > I hope some of this helps. > > If you were after something else, drop me a line. > > Veronica > (I don't work for any of the above companies) > -----Original Message----- > From: Anand Gopal Shirahatti <> > To: <> > Date: 17 February 2002 00:24 > Subject: [fpga-cpu] Remote Target Debugging > > > >Hi, > > > >I am trying to Debug my FPGA based Processor.Currently > I have memory model > Interfaced to it.Where I can store the Instruction > sequence which it can > run.Display the results on Monitor through a VGA > controller. > > > >I am not able Fast up the Debugging process.I am > planning to Use the Remote > Target Debugging Concepts.Where I Would like another > Host Computer should > communicate with the Target FPGA CPU and Run the > Program and Probably > collect the Results and Verify it. > > > >Has any one attempted anything in this Direction.Any > words of Experience > shall be apperciated.Other suggestions to fast up the > Verifications are also > Welcome. > > > >Thanks, > > > >Regards, > >Anand. > > > > > >To post a message, send it to: > >To unsubscribe, send a blank message to: > > > > > > > > > > > > To post a message, send it to: > To unsubscribe, send a blank message to: > > > |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Remote Target Debugging - Veronica Merryfield - Feb 19 17:30:00 2002
|
Hi Anand I took a hike round the net looking for a retargetable debugger. I didn't find anything. I wasn't supprised though. It is hard enough to produce a retargetable compiler but at least the unknown is the machine and it is possible to do. For a debugger, it is dependent on the machine and on the complier. Such a debugger would therefore be intrinsically tied to the compiler. I guess GCC and GDB show this. It would be nice to see something done for LCC. Does anyone know if anything is available. I guess you should follow the example of other CPU vendors and provide some code for a simple monitor similar to what I outlined previously, being of minimal commands and text driven. You would provide a template for the serial interrupt handler and provide the rest of the monitor in source. This could then be used by the user and adapted to the serial device and environment and used with confidence. If you were to provide tooling, then you could supply a debugger. I guess this isn't the info you are looking for. Veronica -----Original Message----- From: Anand Gopal Shirahatti <> To: <> Date: 19 February 2002 12:47 Subject: Re: Re: [fpga-cpu] Remote Target Debugging > >Hi Veronica, > >Thanks for the Information. > >Infact I have worked on the Soft Scope Remote Target Debugger.But I am specifically Looking if there are any very primitive Custom Implementation of these concepts, that if any one has tryed out. > >Now the Problem is that we have Developed the Custom CISC in the FPGA. So if we opt for one of these Standard solutions,then tho it may not be a probelm from the Host software. But we will not get the Monitor software that will Boot up on the Target system.Since it is Custom in our case. So I am Looking for the Primitive Implementations of it. Which we should be able to Develop on Our Own. >Regards, >Anand. >On Mon, 18 Feb 2002 Veronica Merryfield wrote : >> Hi Anand >> >> I'm not 100% sure I understand what you are >> specifically asking for, but I >> will outline a couple of ways of debugging code running >> on a remote target. >> >> 1. Write a simple monitor thsat runs on the target. >> This code communicates >> with your host and your host can do the hard work. >> There is very little a >> monitor needs to communicate with the host to make it >> work. Read and write >> memory will cover a lot, plus go and break. >> The monitor starts up and prompts the host. The host >> can use the write >> command to upload the code. The host can then plant >> break points by writing >> a special instruction. Once planted, the host issues >> the go command. When >> the break point is hit, the monitor starts running. The >> first thing it does >> is to store the registers in a safe place then prompts >> the host. The host >> can use the read command to get the registers, can use >> write to modifiy >> registers using special forms of address and use write >> to enable or disable >> breakpoints etc. The host can reissue the go and the >> registers are restored >> and the monitor returns from interrupt. The break >> command also the host to >> stop execution and force the monitor to run. All the >> hard work is done by >> the host. A simplie text based protocol is used so that >> the monitor can be >> driven by a terminal or a fully fledged source level >> debugger (should you >> have one!). A full source level debugger is a very >> interest project and thre >> are lots of gotchas to watch out for (for intance, what >> do you do about a >> breakpoint being put on a conditional branch). >> >> 2. You could use JTAG to debug. You need to know about >> the boundary chain >> and it has to cover the address, data and control >> busses and have some >> mechanism to stop execution. JTAG is then used to read >> and write memory and >> in some cases small amounts of code would be writen to >> memory and then >> executed but still be in the debugger as helper >> functions. >> >> 3. Some IP could be added to the core in either of the >> above cases to aid >> the debugger and some debuggers have a mix of all of >> this. >> >> Take a look at what ARM do for debugging (access by >> JTAG). Also look at ETM, >> a real time execution trace mechanism. >> >> Also check out Lauterbach and CodeComposer from TI. >> Both are JTAG based. >> >> Sometime back, Motorola had some extra IP with the core >> to aid debugging but >> I can't remember the name. >> >> I hope some of this helps. >> >> If you were after something else, drop me a line. >> >> Veronica >> (I don't work for any of the above companies) >> >> >> -----Original Message----- >> From: Anand Gopal Shirahatti <> >> To: <> >> Date: 17 February 2002 00:24 >> Subject: [fpga-cpu] Remote Target Debugging >> >> >> > >> >Hi, >> > >> >I am trying to Debug my FPGA based Processor.Currently >> I have memory model >> Interfaced to it.Where I can store the Instruction >> sequence which it can >> run.Display the results on Monitor through a VGA >> controller. >> > >> >I am not able Fast up the Debugging process.I am >> planning to Use the Remote >> Target Debugging Concepts.Where I Would like another >> Host Computer should >> communicate with the Target FPGA CPU and Run the >> Program and Probably >> collect the Results and Verify it. >> > >> >Has any one attempted anything in this Direction.Any >> words of Experience >> shall be apperciated.Other suggestions to fast up the >> Verifications are also >> Welcome. >> > >> >Thanks, >> > >> >Regards, >> >Anand. >> > >> > >> >To post a message, send it to: >> >To unsubscribe, send a blank message to: >> >> > >> > >> > >> > >> > >> >> >> >> To post a message, send it to: >> To unsubscribe, send a blank message to: >> >> >> >> > > >To post a message, send it to: >To unsubscribe, send a blank message to: |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )
Re: Re: Remote Target Debugging - Veronica Merryfield - Feb 20 16:36:00 2002
|
All I spoke with a company today and asked them about porting their debugger. They said it took them 2 to 3 man months to port the debugger to a completly new processor core and it would take a couple of weeks max to port to something that had a similer existing processor. In some cases, if the similarities are close it could take a day or two. I asked about educational type licensing and self porting but these guys didn't know much. I'd have to ask one of the owners - I am on good enough terms to do this. The question is, would many people be interested? Veronica |
Stellaris® MCU Family: New Parts, New Package, New Price.
(You need to be a member of fpga-cpu -- send a blank email to fpga-cpu-subscribe@yahoogroups.com )