debugging processor code in Verilog

Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

 

On Monday, June 15, 2015 at 3:16:53 PM UTC-6, beefl...@gmail.com wrote:

Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

I don't mean to suggest ways to extend the simulator itself, I mean to have some sort of tools, either in the testbench or that go along with the simulator that would enable me to follow the program execution closer.

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

 

[michael6866]

On Monday, June 15, 2015 at 5:16:53 PM UTC-4, beefl...@gmail.com wrote:

Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

Do you just want to debug the software itself? If so you can use an M3 emulator to do that.

Or, if you need to do HW/SW co-debugging, then there are some commercial tools you may consider:
(1) If the hardware you want to debug is something else other than CPU (but controlled by the SW), then you can try some hybrid virtual platform solutions. For example, Cadence has a tool called VSP which allows you to run the ARM CPU in ISS level while keep other hardware in RTL. You can break in SW code and observe the RTL activity at any time.
(2) If you need to co-debug SW and CPU itself, then you should see the Indago debugging platform from Cadence which is the ultimate SW/HW co-debugger. You can probe the CPU RTL signal and also doing gdb-like SW debugging at the same time.

Regards,
Michael

 

[rickman]

On 6/15/2015 5:23 PM, beeflobill@gmail.com wrote:

On Monday, June 15, 2015 at 3:16:53 PM UTC-6, beefl...@gmail.com
wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a
Cortex-M3 on it. It has a ROM which is supposed to execute on
power up, and I'm trying to debug the software involved with the
ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be
helpful to bring some debugging (like breakpoints and variable
observation) capability to my Verilog simulator? Or, are there any
general general techniques that would be helpful here (like somehow
using the DPI)?

I don't mean to suggest ways to extend the simulator itself, I mean
to have some sort of tools, either in the testbench or that go along
with the simulator that would enable me to follow the program
execution closer.

Heck, if I could somehow hook GDB up to my simulator (I know,
that's crazy), that would be really swell.

I feel your pain. I have written my own core and had to debug software
using only the HDL simulator. My CPU was simple, so I could easily and
directly view the fetching and execution of instructions. I even set up
an enumerated type on the opcodes so that the simulator would display
the opcode names rather than the raw hex. I don't think that is
feasible in your case since the instructions and operation of the CPU
are much more complex.

I assume your soft core must have a debugging feature for eventual use
on the hardware. Can you tap into that in the HDL simulation and set
break points, etc? Or maybe you can dig into the HDL code enough to see
the bus transactions and log them. Then perhaps a smart tool can figure
out what is being executed and what is being tossed? I'm completely
unaware of just how much work that would be.

Is this an ASIC rather than an FPGA?

--

Rick

 

[nemgreen@gmail.com]

On Monday, 15 June 2015 22:16:53 UTC+1, beefl...@gmail.com wrote:

Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

Mentor has a product called Codelink that provides a complete software debug solution for Questa and Veloce verification environments. It provides access to both CPU register and memory views and allows debug of source code (including access to variable values) and assembly code.
The RTL and software debug are linked so that you can break/step in say RTL and see what CPU instructions are executing and vice-versa.


More details at:
http://www.mentor.com/products/fv/codelink

- Nigel

 

[michael6866]

On Tuesday, June 16, 2015 at 5:02:48 AM UTC-4, nemg...@gmail.com wrote:

On Monday, 15 June 2015 22:16:53 UTC+1, beefl...@gmail.com wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

Mentor has a product called Codelink that provides a complete software debug solution for Questa and Veloce verification environments. It provides access to both CPU register and memory views and allows debug of source code (including access to variable values) and assembly code.
The RTL and software debug are linked so that you can break/step in say RTL and see what CPU instructions are executing and vice-versa.


More details at:
http://www.mentor.com/products/fv/codelink

- Nigel

This looks similar to the ESWD solution (which is part of Cadence's Indago) mentioned in my earlier post (option 2):
http://www.cadence.com/products/fv/Indago_Debug_Platform/pages/default.aspx

However Indago also provides real time debugging in addition to the "DVR" mode, as well as protocol debugging capability.

 

On Monday, June 15, 2015 at 8:41:57 PM UTC-6, rickman wrote:

On 6/15/2015 5:23 PM, beeflobill wrote:
On Monday, June 15, 2015 at 3:16:53 PM UTC-6, beefl...@gmail.com
wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a
Cortex-M3 on it. It has a ROM which is supposed to execute on
power up, and I'm trying to debug the software involved with the
ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be
helpful to bring some debugging (like breakpoints and variable
observation) capability to my Verilog simulator? Or, are there any
general general techniques that would be helpful here (like somehow
using the DPI)?

I don't mean to suggest ways to extend the simulator itself, I mean
to have some sort of tools, either in the testbench or that go along
with the simulator that would enable me to follow the program
execution closer.

Heck, if I could somehow hook GDB up to my simulator (I know,
that's crazy), that would be really swell.

I feel your pain. I have written my own core and had to debug software
using only the HDL simulator. My CPU was simple, so I could easily and
directly view the fetching and execution of instructions. I even set up
an enumerated type on the opcodes so that the simulator would display
the opcode names rather than the raw hex. I don't think that is
feasible in your case since the instructions and operation of the CPU
are much more complex.

I assume your soft core must have a debugging feature for eventual use
on the hardware. Can you tap into that in the HDL simulation and set
break points, etc? Or maybe you can dig into the HDL code enough to see
the bus transactions and log them. Then perhaps a smart tool can figure
out what is being executed and what is being tossed? I'm completely
unaware of just how much work that would be.

Is this an ASIC rather than an FPGA?

--

Rick

It's an ASIC.

The processor does have the arm serial wire debug interface. I've been using it to read/write memory addresses in my testbenches. That way, I could side-step software development to test the peripherals (which has been my part in this project).

I too don't know how deep of a rabbit hole it would be to use the debug interface right through the Verilog.

 

On Tuesday, June 16, 2015 at 11:51:27 PM UTC-6, michael6866 wrote:

On Tuesday, June 16, 2015 at 5:02:48 AM UTC-4, nemg...@gmail.com wrote:
On Monday, 15 June 2015 22:16:53 UTC+1, beefl...@gmail.com wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

Mentor has a product called Codelink that provides a complete software debug solution for Questa and Veloce verification environments. It provides access to both CPU register and memory views and allows debug of source code (including access to variable values) and assembly code.
The RTL and software debug are linked so that you can break/step in say RTL and see what CPU instructions are executing and vice-versa.


More details at:
http://www.mentor.com/products/fv/codelink

- Nigel

This looks similar to the ESWD solution (which is part of Cadence's Indago) mentioned in my earlier post (option 2):
http://www.cadence.com/products/fv/Indago_Debug_Platform/pages/default.aspx

However Indago also provides real time debugging in addition to the "DVR" mode, as well as protocol debugging capability.

Thanks guys. It looks like VSP or codlink may live in my future, but for today, reading about them will have to do. Though, trying to understand how software debug works has been helpful.

I looked into Cadence VSP and Mentor codelink, but I spent more time on VSP because I have access to it. It was a bummer though because I found out we don't have VSP licences .

Reading the VSP document, it isn't clear to me how the mixed (System C and RTL) simulation works. I guess I would learn that with time. Though, the boundary between System C (running nativley on the host) and the RTL (running in simulation land) was kindof scary to me because there isn't 100% cycle accuracy. I guess my goal is to make sure that the ROM is going to work perfectly with our RTL instead of developing application software early.

Application software would eventually be tested with real hardware and fixed, but the ROM requires a metal spin to fix. Breaking that would make our first tapeout much less productive.

I settled on a rather low-tech solution that is basically the same as printing debug messages from code. I created a global variable I could observe directly in the memory (once I figured out where it was), then wrote numbers to it for software stages. I eventually narrowed down the loop that the processor was getting stuck in.


Thanks.

 

[rickman]

On 6/19/2015 8:22 AM, beeflobill@gmail.com wrote:

On Monday, June 15, 2015 at 8:41:57 PM UTC-6, rickman wrote:
On 6/15/2015 5:23 PM, beeflobill wrote:
On Monday, June 15, 2015 at 3:16:53 PM UTC-6, beefl...@gmail.com
wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a
Cortex-M3 on it. It has a ROM which is supposed to execute on
power up, and I'm trying to debug the software involved with the
ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be
helpful to bring some debugging (like breakpoints and variable
observation) capability to my Verilog simulator? Or, are there any
general general techniques that would be helpful here (like somehow
using the DPI)?

I don't mean to suggest ways to extend the simulator itself, I mean
to have some sort of tools, either in the testbench or that go along
with the simulator that would enable me to follow the program
execution closer.

Heck, if I could somehow hook GDB up to my simulator (I know,
that's crazy), that would be really swell.

I feel your pain. I have written my own core and had to debug software
using only the HDL simulator. My CPU was simple, so I could easily and
directly view the fetching and execution of instructions. I even set up
an enumerated type on the opcodes so that the simulator would display
the opcode names rather than the raw hex. I don't think that is
feasible in your case since the instructions and operation of the CPU
are much more complex.

I assume your soft core must have a debugging feature for eventual use
on the hardware. Can you tap into that in the HDL simulation and set
break points, etc? Or maybe you can dig into the HDL code enough to see
the bus transactions and log them. Then perhaps a smart tool can figure
out what is being executed and what is being tossed? I'm completely
unaware of just how much work that would be.

Is this an ASIC rather than an FPGA?

--

Rick

It's an ASIC.

The processor does have the arm serial wire debug interface. I've been using it to read/write memory addresses in my testbenches. That way, I could side-step software development to test the peripherals (which has been my part in this project).

I too don't know how deep of a rabbit hole it would be to use the debug interface right through the Verilog.

I would think if you are doing memory accesses with the debug interface,
it shouldn't be too hard to set break points. You would be able to
directly access most of the data you need without the port, right?
Variable observation can be done directly in the simulator as long as
you know the addresses.

--

Rick

 

[michael6866]

On Friday, June 19, 2015 at 9:23:24 AM UTC-4, beefl...@gmail.com wrote:

On Tuesday, June 16, 2015 at 11:51:27 PM UTC-6, michael6866 wrote:
On Tuesday, June 16, 2015 at 5:02:48 AM UTC-4, nemg...@gmail.com wrote:
On Monday, 15 June 2015 22:16:53 UTC+1, beefl...@gmail.com wrote:
Sorry if this topic has been beaten to death before.....

I'm currently running Verilog simulations of a chip that has a Cortex-M3 on it. It has a ROM which is supposed to execute on power up, and I'm trying to debug the software involved with the ROM. Naturally, I'm finding this difficult.

Are there any tools (proprietary or otherwise) that might be helpful to bring some debugging (like breakpoints and variable observation) capability to my Verilog simulator? Or, are there any general general techniques that would be helpful here (like somehow using the DPI)?

Heck, if I could somehow hook GDB up to my simulator (I know, that's crazy), that would be really swell.

Thanks,
Beeflo

Mentor has a product called Codelink that provides a complete software debug solution for Questa and Veloce verification environments. It provides access to both CPU register and memory views and allows debug of source code (including access to variable values) and assembly code.
The RTL and software debug are linked so that you can break/step in say RTL and see what CPU instructions are executing and vice-versa.


More details at:
http://www.mentor.com/products/fv/codelink

- Nigel

This looks similar to the ESWD solution (which is part of Cadence's Indago) mentioned in my earlier post (option 2):
http://www.cadence.com/products/fv/Indago_Debug_Platform/pages/default.aspx

However Indago also provides real time debugging in addition to the "DVR" mode, as well as protocol debugging capability.

Thanks guys. It looks like VSP or codlink may live in my future, but for today, reading about them will have to do. Though, trying to understand how software debug works has been helpful.

codelink and VSP don't belong to the same category. The product similar to codelink is ESWD which is part of Indago.

I looked into Cadence VSP and Mentor codelink, but I spent more time on VSP because I have access to it. It was a bummer though because I found out we don't have VSP licences .

Reading the VSP document, it isn't clear to me how the mixed (System C and RTL) simulation works. I guess I would learn that with time. Though, the boundary between System C (running nativley on the host) and the RTL (running in simulation land) was kindof scary to me because there isn't 100% cycle accuracy. I guess my goal is to make sure that the ROM is going to work perfectly with our RTL instead of developing application software early.

The peripheral RTL is cycle accurate while the CPU is not.

Application software would eventually be tested with real hardware and fixed, but the ROM requires a metal spin to fix. Breaking that would make our first tapeout much less productive.

OK, so the intention is really to test the hardware instead of the software.. VSP is ideal for the latter. For the former you should look into ESWD (Indago) where the CPU executes in cycle accurate mode:

http://www.cadence.com/products/fv/Indago_Embedded_Software_Debug_App/pages/default.aspx

I settled on a rather low-tech solution that is basically the same as printing debug messages from code. I created a global variable I could observe directly in the memory (once I figured out where it was), then wrote numbers to it for software stages. I eventually narrowed down the loop that the processor was getting stuck in.


Thanks.

Regards,
Michael