draft: GDB-stub goes to vhdl, how good is this idea ?

[legacy]

This is an idea, just an idea, a friend of mine has developed his own softcore recicling the debug tap from the OpenCores in OpenRISC's ADI-TAP, and then has complained that the ADI-JTAG stub is too complex, so he wants the whole engine written in VHDL, removing the jtag and using an uart protocol (GDB usually talks over an ASCII protocol, over the uart), so he'd like to develop the GDB-stub in vhdl and able to interface the CPU and to interact with the GDB-host (PC side, /usr/bin/gdb) over the serial line.

guys, what do you think ?

[ataradov]

guys, what do you think ?

Creating a parser for a serial protocol in VHDL will involve a huge state machine. And he already has a state machine - his CPU Just instantiate another core (with no debug components and simplified, if possible) and write a parser in assembly. If he feels confident he can make it in VHDL, it will be a piece of cake to write interface software without a debugger.

[legacy]

so basically it's a bullshit, like the worst idea ever 

[ataradov]

Not necessarily. It is unconventional, for sure, but can be done if needed.

But GDB is useful if you have support for that processor in GDB and corresponding libraries. Having a tool chain will nor hurt either. Does he have al of this? Or is his core just an implementation of existing architecture?

[legacy]

But GDB is useful if you have support for that processor in GDB and corresponding libraries.
Having a tool chain will nor hurt either. Does he have al of this?
Or is his core just an implementation of existing architecture?

he has developed a pipelined MIPS-1 (R2K) soft core, without FPU and with reduced interrupts support (Cop0)
it does not have TLB and cache, and he has a lot of difficulties in attaching a debugger TAP (especially JTAG-ADI)

[legacy]

GDB has interesting gdb-stub, gdb-server
and gdb-gui like these:

• cgdb
• kgdb

I do not like the JTAG-ADI (fpga side) + ADI-GDB-BRIDGE (host side) approach

[ataradov]

I personally would re-evaluate a need for debugger or priority. What is the goal of all this? If this is just an exercise in VHDL and no future development is planned, then it is probably better to finish it off with a somewhat standard debugger architecture, even if it is ugly and hard (it is not like the rest of GDB is beautiful). Same goes for a real production stuff - bad standards are better than home brewstuff in most cases, unless you are really committed and sure in your abilities to push for a new standard.

For hobby use, I don't think the debugger is necessary at all, but I'm generally biased against debuggers.

[nctnico]

so basically it's a bullshit, like the worst idea ever 

I'm not quite sure. A small cpu core like the picoblaze could handle the protocol. These are simple (and almost fun) to program in assembly.
@Ataradov: the GDB protocol is also standard so if you can implement that it still adheres to a standard. Personally I'm not a fan of JTAG because it is often very obfustigated to use. Many layers stacked on top of eachother with many places for things to go wrong.

[legacy]

What is the goal of all this?

I have never understood what he wants to do. In first place, there is no need for another softcore, we already have NIOS, LEON, ZPU, etc, also we have hybrid solution like ARM+FPGA (e.g. DE1 board), able to run linux (OpenRISC has now a specific uclibc stage 4), while his softcore comes with no TLB (no MMU), no cache, and a very reduced exception engine: in short, even if there are board with arduino-line pins, it's less useful than an arduino!
for hobby (good occasion to learn by having fun) I have already designed and suggested him a debug TAP, I have designed its protocol to be the easiest, I have written the host interface in C (with wrappers to simplify both the module test and the system integration test), but he refuses everything because he want the goddam gdd, which costs a very complex engine, especially if you also want the jtag

I am a bit tired about his project, I am tired to provide him solutions which he refuses for his motivation, which sounds "I MUST use gdb, I MUST have jtag" (even if it's for hobby purpose, I do not believe it's for commercial, as there is no need for an other soft core, and in case { ZPU, LEON, NIOS*, *BLAZE } have a better support by sever order of magnitude)

I have already written a linker-script, a full-patch for gcc-mips in order to force alignment load/store (in order to simplify the exception handler, as his softcore is not able to handle unaligned memory access exceptions, and it comes with no dedicated instructions, still to be implemented and tested), a bsp, everything integrated within geany with automagically generation of makefile, but he is still using the manual way with no linker script, which makes everything more complex to be handled as it requires more manual work

it is not like the rest of GDB is beautiful

things made by G-boys (G stands for GNU) are always thousand light years far from the concept of being simple and beautiful, these guys are complex by design, and sometimes (too often) they cause more problems than how many they solve, e.g. tar worked on UNIX until they have "improved" and since then we still have a lot of troubles

gdb is a very complex amount of stuff, even if the gdb-stub is simple, the gdb engine goes complex

For hobby use, I don't think the debugger is necessary at all, but I'm generally biased against debuggers.

it's useful and funny when you have to verify what happens inside a softcore and you can trust the software because you can't trust the hardware because bugs are there
e.g. his softcore had a lot of bugs with "delayed branch" plus other bad things, so the "monitor" (a piece of software, written in assembly, and able to catch exceptions, interrupts, and able to dump the CPU-registers content) was bugged because of these hardware bugs, so register RA was reported completely wrong (which made me things a bug in the C compiler) when the problem was elsewhere

when I implemented my TAP, I was able to show him where was the bug, even if is he refuses to use my TAP because he wants his damn GDBGDBGDBGDBGGDB even if it never comes into a working & stable state

let me say: sometimes being stubborn in things which have already proved to be the wrong choice (perhaps because they are too complex, perhaps you can't implement it in a comfortable way), makes you to look like the best moron ever!

[legacy]

the GDB protocol is also standard so if you can implement that it still adheres to a standard.
 Personally I'm not a fan of JTAG because it is often very obfustigated to use. Many layers stacked on top of eachother with many places for things to go wrong.

yes, I think so, the ADI-JTAG looks obscure, unclear, unintelligible, hard to be understood and handled.

[legacy]

A small cpu core like the picoblaze could handle the protocol

a debug processor! Like the one used by AnalogDevices to debug their Blackfin DSP!
the B1000 cable has a BF535 chip, used as debug processor 

Code: [Select]

Serial Wire Interface for Debugging

# open                                     
PHY_protocol=uart
device=/dev/ttyUSB0
client.port=na
ans=(1)

# con
connected
ans=(1)

# ping
PONG
ans=(1)

# scan
device0:
   class0 reg_size[]={ 8 8 4 2 } bytes
scan probe completed in 13 tries
ans=(1)

# regs
device0 ""
 + class0
c0.reg0 "" = {  0  0  0  0  0  0  0  0 }
c0.reg1 "" = {  0  0  0  0  0  0  0  0 }
c0.reg2 "" = {  0  0  0  0 }
c0.reg3 "" = {  0  0 }
ans=(1)
#

my TAP comes with a very simple protocol, simpler than GDB-protocol, it's uart-driven (even if it's not ASCII) and it comes with a very useful interface on the host side, it's "select" driven, you can have multi clients, so a GDB-bridge it's also possible, like a piece of cake to be developed

on the host side it has a shell, you can scan resources on the remote TAP, you can probe, and then read/write registers from/to the remote TAP, something like …
how many devices do you have in your grid ?
how many classes per device ?
how many registers per class ?
and how many bits have these registers ?

its finite state machine comes with very reduced set of states, so it's less complex than a CPU by different orders of magnitude, so it makes sense. I have developed it because I need something to interface my fpga when I need to debug things like VDU, softcore ISA validation, DMA, LCD-driver

[legacy]

I am a bit tired about his project, I am tired to provide him solutions which he refuses for his motivation, which sounds "I MUST use gdb, I MUST have jtag"

e.g. he refuses my boot loader, written in mips-assembly, provided with an host application which is able to load an elf-file out of the mips-toolchain, split it into .data section and .text section , and then upload them into fpga, because he MUST use gdb for this purpose, that even if his damn gdb is still not working and causes a lot of exception and data corruption 


ah friend (I can't say screw you to him, even if sometimes I am really tempted  )

[Kalvin]

+1 picoblaze

Picoblaze has also a C compiler available. I haven't used it, but it is available if writing the debugger state machine in assembly seems too complex.

Using "external" debugger allows halting the target core, single stepping, observing and modifying register values, observing stack frame, variables, memory and other fun stuff without state corruption. But it is a matter of taste how to use the debugger.

[ataradov]

Personally I'm not a fan of JTAG because it is often very obfustigated to use.

I'm working on a project that involves very heavy use of ARM SWD/JTAG interface. At first I was put off by all the complexity, but then, as I learned how it all works, I got to like it. It is not like it is the best thing ever, and there is some legacy, but in general it is not that bad.

There are many things people don't think about, especially in performance and reliability department.

Your UART works at 115200 bsp, may be a bit more. JTAG can work at 16+ MHz.  And this is important for debuggers that can take advantage of this (I don't think GDB or any front end for GDB can).

What happens when a byte gets lost of damaged in your protocol? How does it handle multicore systems?

There are many things that "grown up" debug interfaces do that are not instantly obvious.

And my point is, if you are learning something, it is better to learn industry standard interfaces. For your own MCU you can do whatever you want, but when you get to work with an actual device, it will have SWD/JTAG, so might as well learn how to take full advantage of that.

[legacy]

Your UART works at 115200 bsp

my TAP can go up to 20Mbyte/sec, using bulk over burst mode

the protocol has been designed to be used for fast upload/download
including a RAM and ROM emulator: one protocol, different engines!

What happens when a byte gets lost of damaged in your protocol?

my TAP has 2 CRC, one for input-stream, one for output-stream
if something goes wrong the packed is rejected on both side (host, and target)
there is a stop and retry

How does it handle multicore systems?

my TAP can handle sub devices independently
- core (and their registers, general purpose registers, superuser register, floating point registers, custom registers)
- local bus
- emulated ram
- emulated rom
- shared bus (with semaphores)
- DMA
- virtual console

the real limitation is: a cpu which comes in Harvard design needs 5 sub-devices at least (instruction ram is separated from data/stack ram)
and the protocol is limited up to 32-sub devices

a virtual console is memory mapped by the tap, so it's not a physical device
but, from the point if view of the CPU, it looks like an UART (put_char, get_char, check_if_tx_is_ready, check_if_rx_is_ready, FIFO_TX, TIFO_RX)
it's useful to provide a console (not interrupt driven) when you do not have the hardware

[legacy]

currently I am using a slow link @ 1Mbps
I need to downgrade the soft core clock

[ataradov]

my TAP can go up to 20Mbyte/sec, using bulk over burst mode

But how it is attached to the actual target?

my TAP has 2 CRC, one for input-stream, one for output-stream
if something goes wrong the packed is rejected on both side (host, and target)
there is a stop and retry

SWD/JTAG has a feature, where result of a memory access is stored inside the debug unit, so that if transfer has failed, you get the buffered value, and don't do a read again. This is needed when you work with memory-mapped I/O in case if access causes side-effects. For example, many flag registers are clear on read, so you only get one shot at reading them.

I'm not saying it is impossible to design a good system, but small things like that do make a difference, and after you implement them all, you will end up with the same level of complexity.

Dealing with secure systems with varying privileges for different buses/memory regions is another story.

I personally rather go with industry standards.

[legacy]

how it is attached to the actual target?

I have designed a pcb, it comes with a fast USB chip (Cyprex) directly wired to the fpga and synchronously handled
while on the host side (PC), linux sees a special usb-bulk device (over a custom kernel module, which is still under development)

[nctnico]

What happens when a byte gets lost of damaged in your protocol?

The biggest problem with JTAG is that it is synchronous and debuggers are connected with relatively long wires. If you turn on a mains powered device during a JTAG transfer it is very likely the JTAG transfer get screwed up beyond recovery. UART (or USB) is much more resilient to these kind of events.

[legacy]

SWD/JTAG has a feature, where result of a memory access is stored inside the debug unit, so that if transfer has failed, you get the buffered value, and don't do a read again. This is needed when you work with memory-mapped I/O in case if access causes side-effects. For example, many flag registers are clear on read, so you only get one shot at reading them.

nice trick, my TAP does not have it, while I have seen something similar with BDM on MC68332, which comes with clear on read || write devices.

I'm not saying it is impossible to design a good system, but small things like that do make a difference, and after you implement them all, you will end up with the same level of complexity.

to be honest I am very tired of GDB and these stuff, I often happen to have a lot of problems recompiling them on my embedded boards
especially when I have to recompile them on machines that are not x86 (the most used)

e.g.

Code: [Select]

2015-12-29--21-41-23---2015-12-29--21-50-00 - mips-be-glibc emerge  dev-util/cgdb - failure - root


Code: [Select]

2015-12-29--21-10-01---2015-12-29--21-15-00 - x86-be-glibc emerge  dev-util/cgdb - success - root

while my tools do always compile without any troubles as they are written in pure ANSI/C without ugly wicked tricks!

Dealing with secure systems with varying privileges for different buses/memory regions is another story.

I personally rather go with industry standards.

My TAP is not designed for the industry, it's designed for hobby, more specifically to have fun instead of having troubles with GNU, G-BOYS and their stuff
It's not better, it's not THE solution, I am not interested in Copyright, Royalties, reinventing the wheel in a new standard to do money with.
My TAP simply compiles everywhere without all the G-crap, and it works as expected.

When I have to do professional job-tasks I do not use GDB, I use Keil and Analog Devices.
I have bought their professional debuggers and I am fine with them 

[ataradov]

I have designed a pcb

Well, yes, with custom (and expensive) hardware anything can be done. But CMSIS-DAP can be implemented on any MCU with USB (all you need is HID support) and has plenty of performance for normal debugging. Trace features many need a bit more bandwidth, but with 1024-byte packets, event that is not really a big deal.

[ataradov]

JTAG transfer get screwed up beyond recovery.

There is no way to screwup JTAG interface itself. Particular transaction will be gone, of course, but software can always recover. That's one of the design objectives.

[legacy]

Well, yes, with custom (and expensive) hardware anything can be done

a papilio-pro costs ~100 euro, while my board costs 160 euro and comes with a 2Mbyte NVRAM, 8Mbyte DRAM, and a super fast Cyprex chip for the TAP. A Cyprex demo board costs 50 euro, so … I am really fine!

I can adapt my protocol (from vhdl to C) to work over HID, and in this way I could cover MPUs: the problem is, again, I am not interested!

[ataradov]

A Cyprex demo board costs 50 euro, so … I am really fine!

Again, we are talking about different thins here.

Inventing new stuff for hobby is perfectly fine.

I'm more industry-oriented. So I'm taking about $10 development boards that include a target board and a debugger. There is no way to put a Cypress chip on there. And it is very fortunate that everything moves towards very cheap debugger hardware.

[legacy]

I'm more industry-oriented

$10 development boards

It sounds you are kidding

In first place, do really use gdb for serious job-tasks?

In second place, here "development boards" costs in order of thousands
e.g. Keils costs 1600 euro, just for the toolchain + debugger license, plus 700 euro for the debug cable/pro
my e500 board (used in automotive) costs 2500 euro, its debug engine (including Windriver + Lauterbac + debug cable) costs 32.000 euro
things from Green Hills (e.g. AdaMulti) cost more and more!

and let me say nobody sane will ever reinvent Lauterbach GmbH, they are a German electronic company specialized in in-circuit emulators and logic analyzers used for debugging embedded systems

in third place, for professional job you MUST use certified tools (especially in avionics)