draft: GDB-stub goes to vhdl, how good is this idea ? - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: December 29, 2015, 11:06:28 pm
content: 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 theADI-JTAG stubis 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?

author: ataradov
author_rank: Super Contributor
timestamp: December 30, 2015, 09:15:04 am
content: Quote from: legacy on December 29, 2015, 11:06:28 pmCreating a parser for a serial protocol in VHDL will involve a huge state machine. And he already has a state machine - his CPUJust 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.

author: legacy
author_rank: Super Contributor
timestamp: December 30, 2015, 10:52:12 am
content: so basically it's a bullshit, like the worst idea ever

author: ataradov
author_rank: Super Contributor
timestamp: December 30, 2015, 10:56:46 am
content: 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?

author: legacy
author_rank: Super Contributor
timestamp: December 30, 2015, 11:11:23 am
content: Quote from: ataradov on December 30, 2015, 10:56:46 amhe 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)

author: legacy
author_rank: Super Contributor
timestamp: December 30, 2015, 11:14:10 am
content: GDB has interesting gdb-stub, gdb-serverand gdb-gui like these:cgdbkgdbI do not like the JTAG-ADI (fpga side) + ADI-GDB-BRIDGE (host side) approach

author: ataradov
author_rank: Super Contributor
timestamp: December 30, 2015, 07:09:04 pm
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: December 31, 2015, 12:05:27 pm
content: Quote from: legacy on December 30, 2015, 10:52:12 amI'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.

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 01:07:14 pm
content: Quote from: ataradov on December 30, 2015, 07:09:04 pmI 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 jtagI 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,buthe is still using the manual way with no linker script, which makes everything more complex to be handled as it requires more manual workQuote from: ataradov on December 30, 2015, 07:09:04 pmthings 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 troublesgdb is a very complex amount of stuff, even if the gdb-stub is simple, the gdb engine goes complexQuote from: ataradov on December 30, 2015, 07:09:04 pmit'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 theree.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 elsewherewhen 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 statelet 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!

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 01:11:38 pm
content: Quote from: nctnico on December 31, 2015, 12:05:27 pmyes, I think so, the ADI-JTAG looks obscure, unclear, unintelligible, hard to be understood and handled.

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 01:23:15 pm
content: Quote from: nctnico on December 31, 2015, 12:05:27 pma debug processor! Like the one used by AnalogDevices to debug their Blackfin DSP!the B1000 cable has a BF535 chip, used as debug processorCode:Serial Wire Interface for Debugging# openPHY_protocol=uartdevice=/dev/ttyUSB0client.port=naans=(1)# conconnectedans=(1)# pingPONGans=(1)# scandevice0:class0 reg_size[]={ 8 8 4 2 } bytesscan probe completed in 13 triesans=(1)# regsdevice0 ""+ class0c0.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 developedon 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

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 02:36:56 pm
content: Quote from: legacy on December 31, 2015, 01:07:14 pme.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 corruptionah friend (I can't say screw you to him, even if sometimes I am really tempted)

author: Kalvin
author_rank: Super Contributor
timestamp: December 31, 2015, 02:45:43 pm
content: +1 picoblazePicoblaze 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.

author: ataradov
author_rank: Super Contributor
timestamp: December 31, 2015, 10:11:05 pm
content: Quote from: nctnico on December 31, 2015, 12:05:27 pmI'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.

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 11:55:19 pm
content: Quote from: ataradov on December 31, 2015, 10:11:05 pmmy TAP can go up to 20Mbyte/sec, using bulk over burst modethe protocol has been designed to be used for fast upload/downloadincluding a RAM and ROM emulator: one protocol, different engines!Quote from: ataradov on December 31, 2015, 10:11:05 pmmy TAP has 2 CRC, one for input-stream, one for output-streamif something goes wrong the packed is rejected on both side (host, and target)there is a stop and retryQuote from: ataradov on December 31, 2015, 10:11:05 pmmy 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 consolethe 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 devicesa virtual console is memory mapped by the tap, so it's not a physical devicebut, 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

author: legacy
author_rank: Super Contributor
timestamp: December 31, 2015, 11:57:38 pm
content: currently I am using a slow link @ 1MbpsI need to downgrade the soft core clock

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 12:03:06 am
content: Quote from: legacy on December 31, 2015, 11:55:19 pmBut how it is attached to the actual target?Quote from: legacy on December 31, 2015, 11:55:19 pmSWD/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.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 12:56:47 am
content: Quote from: ataradov on January 01, 2016, 12:03:06 amI have designed a pcb, it comes with a fast USB chip (Cyprex) directly wired to the fpga and synchronously handledwhile on the host side (PC), linux sees a special usb-bulk device (over a custom kernel module, which is still under development)

author: nctnico
author_rank: Super Contributor
timestamp: January 01, 2016, 01:04:12 am
content: Quote from: ataradov on December 31, 2015, 10:11:05 pmThe 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.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 01:12:34 am
content: Quote from: ataradov on January 01, 2016, 12:03:06 amnice 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.Quote from: ataradov on January 01, 2016, 12:03:06 amto 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 boardsespecially when I have to recompile them on machines that are not x86 (the most used)e.g.Code:2015-12-29--21-41-23---2015-12-29--21-50-00 - mips-be-glibc emerge dev-util/cgdb - failure - rootCode:2015-12-29--21-10-01---2015-12-29--21-15-00 - x86-be-glibc emerge dev-util/cgdb - success - rootwhile my tools do always compile without any troubles as they are written in pure ANSI/C without ugly wicked tricks!Quote from: ataradov on January 01, 2016, 12:03:06 amMy 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 stuffIt'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

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 01:21:17 am
content: Quote from: legacy on January 01, 2016, 12:56:47 amWell, 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.

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 01:22:59 am
content: Quote from: nctnico on January 01, 2016, 01:04:12 amThere 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.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 01:30:20 am
content: Quote from: ataradov on January 01, 2016, 01:21:17 amapapilio-procosts ~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!

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 01:34:29 am
content: Quote from: legacy on January 01, 2016, 01:30:20 amAgain, 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.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 01:50:35 am
content: Quote from: ataradov on January 01, 2016, 01:34:29 amQuote from: ataradov on January 01, 2016, 01:34:29 amIt sounds you are kiddingIn first place, do really use gdb for serious job-tasks?In second place, here "development boards" costs in order of thousandse.g. Keils costs 1600 euro, just for the toolchain + debugger license, plus 700 euro for the debug cable/promy e500 board (used in automotive) costs 2500 euro, its debug engine (including Windriver + Lauterbac + debug cable) costs 32.000 eurothings 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 systemsin third place, for professional job you MUST use certified tools (especially in avionics)

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 01:53:18 am
content: Quote from: legacy on January 01, 2016, 01:48:39 amWe are on different sides of the industryI'm talking about MCU vendors, not people who use MCUs.Quote from: legacy on January 01, 2016, 01:48:39 amOf course not. I do use GCC toolchain and very happy with it, would not change it for any other even if some one else pays. Well, maybe IAR, but I do hate Keil.I don't use debuggers much. I'm pretty happy with other ways of debugging.

author: nctnico
author_rank: Super Contributor
timestamp: January 01, 2016, 02:05:16 am
content: Quote from: ataradov on January 01, 2016, 01:22:59 amYes, but unfortunately the recovery part is always forgotten in the software

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 02:05:59 am
content: Quote from: nctnico on January 01, 2016, 02:05:16 amCould not agree more

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 02:14:34 am
content: Quote from: ataradov on January 01, 2016, 01:53:18 amI hate gcc and everything comes from GNU (including emacs and gdb), in first place G-boys& their friends are not good programmers, these dudes too often do "jerk child code" with too much complexity, which is too ugly to be supported (pay me to see their sources, I am horrified)I am a gentoo/MIPS supporter, I have a lot of troubles with gcc, e.g. just to tell you the last maleficent, I am supporting an old SGI machine and I had to switch to gcc 5.2, which is currently "experimental" (it means not included in the gentoo portage, the last available is gcc v4.9), because the atomic-functions were not working as expected for R12K CPUsin short the whole SMP, and the whole userland, was crashing up and I needed a lot of pills because the compiler is a @#@$@ crap!I have fixed the jam just switching to v5.2 (which means ... opening an overlay, invoking crossdev, forcing a new cross compiler, fixing it ... 5 days of over work and blasphemy) and recompiling everything in the right way: I have now a working SMP plus a working uclibc-stage4, I am completed, but … I still HATE their compiler!Have you ever seen inside gcc source code ? My friend's softcore does not handle unaligned memory access, so I had to manually patch gcc to force it to avoid unaligned memory access, it's a piece of cake with LLVM, while it was a nightmare with gcc!!! It took 8 days of blasphemy!and do I have to tell you what happened with gcc v4.1 on HPPA v2 ? I remember when applications compiled by gcc -O2 took their branches (if (condition) then else) in randomly way because the compiler had a bug! It took 3 month of blasphemy, because I was not sure that the problem was the compiler (I was used to trust it, so I was looking into different direction, including hardware failures in ram)in short, don't say "gcc" for job-tasksQuote from: ataradov on January 01, 2016, 01:53:18 amI hate their IDE, but everything else (including their support and assistance) is more than comfortable (and they are very kind on the phone)

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 02:29:00 am
content: Quote from: legacy on January 01, 2016, 02:14:34 amHere is your problemI would not want to go into the guts of GCC. Well, I had to a few times for AVR, and I did not enjoy it.That's why I use ARM. They actually maintain official toolchain, that always works and always up to date and available for variety of platforms. Never had any problems with it and if ARM engineers suffer to make it work, I feel for them, but it is not my problem.I hope Clang/LLVM get up to speed soon on all major platforms, not just x86.

author: nctnico
author_rank: Super Contributor
timestamp: January 01, 2016, 02:55:04 am
content: Using anything for a less common platform is going to land you in a world of pain due to lack of support. That is not GCC's fault! I have used GCC in the past on a MIPS based Linux platform but I didn't had any problems with the GCC compiler.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 11:09:40 am
content: Which System and Which Work, buddy ?if you mean, I got the last trunk from OpenWRT and then I built a kernel+rootfs for the last routerwell, sure, it works out of the box, butit's not the point!!!the point is: do you know how hard was the effort under the hood in order to get this purpose?...edit: details removed...the point with gcc: an easy task too often comes into troubles, which requires too much effort to be solved!

author: ataradov
author_rank: Super Contributor
timestamp: January 01, 2016, 11:34:22 am
content: Stop whining and create a better compiler, what stops you?Unlike you, "G-Boys" have created a compiler that is used in a lot of machines, and at the moment it is the best we have, even if it is not pretty.If you hate it so much, don't work with it, leave it alone.

author: nctnico
author_rank: Super Contributor
timestamp: January 01, 2016, 11:35:34 am
content: Quote from: legacy on January 01, 2016, 11:09:40 amYes. That is a world of pain which is why you shouldn't drift away from the beaten path O0 IIRC the system I worked on had a MIP32 core. The systems you are writing about are very archaic so it might be better to stick to old versions of GCC which work for those.

author: legacy
author_rank: Super Contributor
timestamp: January 01, 2016, 04:32:51 pm
content: Quote from: nctnico on January 01, 2016, 11:35:34 amyes, absolutely

author: helius
author_rank: Super Contributor
timestamp: January 01, 2016, 05:52:40 pm
content: Even GNU developers have decided that GCC is doomed.https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00457.html