Show HN: JPDB, GDB for Your Waveforms(github.com)
github.com
Show HN: JPDB, GDB for Your Waveforms
https://github.com/1024bees/dang
6 comments
Oops, I assumed maybe too much familiarity with the problem. The premise of the problem is this:
You're designing a CPU, either for your job or for fun, in your favourite hardware description language. Systemverilog, vhdl, hell maybe you went to Berkeley/ work at sifive and you use chisel. if you aren't familiar with HDLs or digital logic design, you should look into them, it is fun.
to test your CPU, you use a simulator, and give your simulated CPU a program to execute. But shit -- you have a bug, and some instruction is producing the wrong value. It would be really nice to step through the code and see what was happening inside your CPU to pinpoint where the bug is.
At this point, you can tell the simulator to generate a waveform (some call it a dump, maybe there are other names). The waveform will contain every signal inside of your design -- every clock, every control signal, you name it. This is typically a MASSIVE amount of data, and people analyze these waveforms. And worse yet, you just have "raw signals". To find out what PC is being executed, you have to pull up the PC signal in the waveform viewer, and then all of the register signals, and then cross correlate that with the disassembly; in short, you get very intimate information about the design, but organizing that information is the responsibility of the person using the waveform viewer, and it can be tedious.
The insight this tool makes is that all of the data you need to have a gdb-like interface when debugging a simulated CPU is already in the waveform, jpdb just organizes and presents the data in a way that is easy for the developer to parse.
You're designing a CPU, either for your job or for fun, in your favourite hardware description language. Systemverilog, vhdl, hell maybe you went to Berkeley/ work at sifive and you use chisel. if you aren't familiar with HDLs or digital logic design, you should look into them, it is fun.
to test your CPU, you use a simulator, and give your simulated CPU a program to execute. But shit -- you have a bug, and some instruction is producing the wrong value. It would be really nice to step through the code and see what was happening inside your CPU to pinpoint where the bug is.
At this point, you can tell the simulator to generate a waveform (some call it a dump, maybe there are other names). The waveform will contain every signal inside of your design -- every clock, every control signal, you name it. This is typically a MASSIVE amount of data, and people analyze these waveforms. And worse yet, you just have "raw signals". To find out what PC is being executed, you have to pull up the PC signal in the waveform viewer, and then all of the register signals, and then cross correlate that with the disassembly; in short, you get very intimate information about the design, but organizing that information is the responsibility of the person using the waveform viewer, and it can be tedious.
The insight this tool makes is that all of the data you need to have a gdb-like interface when debugging a simulated CPU is already in the waveform, jpdb just organizes and presents the data in a way that is easy for the developer to parse.
What is waveform? How it is supposed to impact the debugging process. More info is needed to atract general audience, not everyone is desiging own CPU even here.
The target audience knows what a waveform is.
Not necessarily, no. I've dabbled in VHDL, but not remotely close to being proficient. Is it useful for that kind of thing? I don't recognize the term.
Maybe this project unlocks be getting into it? But as is, I have no idea if this makes it easier, or is even related.
I thought it was a software defined radio thing.
Maybe this project unlocks be getting into it? But as is, I have no idea if this makes it easier, or is even related.
I thought it was a software defined radio thing.
Is this something you would combine with a logic analyzer?
Just tried it, neat tool!
I've been working on JPDB is a GDB like debugger for waveforms. if you give JPDB a waveform* and some other information, then you can step through the program that was executed when that waveform was created.
i say GDB-like because JPDB has it's own GDB client (its called shucks), that implements the client side logic of the GDB protocol faithfully, but doesnt have all of the GDB niceties (like python integration, etc). this allows the project to be specialized on debugging waveforms specifically, when compared to another approach like connecting to a gdb client
JPDB integrates with the waveform viewer surfer (https://surfer-project.org/), so you can look at other signals there. this is still ongoing because the underlying protocol (WCP) is a little Fresh
if you're developing your own CPU, give it a shot. Superscalar designs arent supported yet but it would be pretty straightforward, just give me your waves ( i am touching my fingers together villainously as i type this) and i will make it happen
also if you want to use system with a "normal" gdb client, the dang library presents a gdbstub server, so you can run that and connect to it.
here's a demo but it should work on your local machine if you follow the readme:
https://www.youtube.com/watch?v=EOo1aG_wcJg