| --- Log opened Mon May 09 00:00:58 2016 | ||
| olofk | Dan__: Ahh. So you're the Dan who's been answering more or less all of the forum posts on OpenCores since a while ago :) | 02:47 |
|---|---|---|
| olofk | I've been meaning to take a closer look at ZipCPU. First intention would of course be to add FuseSoC support | 02:48 |
| wallento | shorne: I am a bit lost to be honest. Those breakpoint traps are used when no hardware breakpoints are available, right? | 04:08 |
| _franck__ | wallento: yes. When you ask gdb to put a breakpoint somewhere is save the targeted instruction, replace it with a trap | 04:51 |
| wallento | ah, got it | 04:51 |
| wallento | thanks _franck__ | 04:52 |
| wallento | did we have this before? | 04:53 |
| _franck__ | https://github.com/ntfreak/openocd/blob/master/src/target/openrisc/or1k.c#L915 | 04:53 |
| wallento | I am wondering how this integrates with multicore then | 05:15 |
| wallento | because changing the code changes it for all, so the excpetion handler needs another criterion too, correct? | 05:16 |
| ZipCPU|Laptop | olofk: (From another IRC chat program ----) Yes, I am the "Dan" that has been trying to answer all the forum posts. | 05:27 |
| ZipCPU|Laptop | I just found that the forums got a touch too ... quiet. | 05:28 |
| wallento | well formulated ;) | 05:39 |
| olofk | ZipCPU|Laptop: Agree with wallento :) Much appreciated to have some life there, even though we have basically given up on OpenCores | 06:27 |
| ZipCPU|Laptop | Well gosh ... thanks! | 06:46 |
| ZipCPU|Laptop | My biggest problem there is that there are so many questions I don't know how to answer. | 06:47 |
| ZipCPU|Laptop | Most of my answers simply consist of looking through the projects list for something that might help someone, and then pointing them to the project and/or the reference documentation for the project. | 06:47 |
| ZipCPU|Laptop | Once in a while I get ... gutsy ... and actually try looking through some source code to see what's going on, but that's rather rare. | 06:47 |
| ZipCPU|Laptop | As for FuseSoC, I'll admit I've stared at it a couple times wondering what it did. I haven't found a really good quick and simple explanation of it. | 06:50 |
| ZipCPU|Laptop | From what I gather, it 1) replicates cores from servers into a project, and 2) manages building the interconnect for those same cores? | 06:50 |
| olofk | ZipCPU|Laptop: Not quite. It doesn't handle any interconnects. Its primary purpos is to make it easy to reuse existing cores in your project, so that you don't have to write UARTs, SPI controllers and such from scratch, or make a local copy of an existing core in your repo | 07:02 |
| olofk | It also provides an abstraction to simulators and FPGA build tools, so that you can run your code through multiple simulators without having to create custom scripts | 07:02 |
| ZipCPU|Laptop | How hard is it to make something fusesoc compatible? Is it just the difficulty of building the .core file? | 07:03 |
| olofk | ZipCPU|Laptop: One of the core design principles is that you shouldn't have to make changes to your code. Even the .core file can be kept outside of the repo | 07:04 |
| ZipCPU|Laptop | olofk: Okay, but is that the only "work" that needs to be done to make something fusesoc compatible? Or are there more integration pieces that need to take place as well? | 07:05 |
| olofk | So the first step often consists of listing your RTL and testbench files and put them in the .core file, define which simulators that are supported. | 07:05 |
| olofk | ZipCPU|Laptop: For simulation that is often enough | 07:06 |
| ZipCPU|Laptop | olofk: I have become a *big* fan of Verilator, and the flexibility it gives me. Does FuseSoC support a Verilator "simulation"? | 07:07 |
| olofk | For FPGA building, it depends on what your current infrastructure looks like. It's usually just a matter of breaking out constraints and pin mapping to separate files and add them to thefile | 07:07 |
| olofk | ZipCPU|Laptop: Yes. FuesSoC supports verilator, both in c++ and systemC mode. There are also some utility cores that makes it easy to load elf files directly into the simulation model and hook up OpenOCD to run interactive debugging towards a simulated system | 07:08 |
| ZipCPU|Laptop | olofk: Do you mean it builds the FPGA build scripts as well? Like ... a series of Makefile's that will call the proprietary tools to build something in an (gasp!) automated fashion? | 07:08 |
| olofk | ZipCPU|Laptop: Yes :) | 07:10 |
| olofk | Nothing fancy there. I'm trying to keep the FuseSoC part as thin as possible to support all user flows | 07:11 |
| ZipCPU|Laptop | That's cool. Every time I've done it to date it has always been by hand. | 07:11 |
| ZipCPU|Laptop | Have you put anything together that automatically builds interconnects? That's been the other hands-on piece I always find myself rebuilding for every project. | 07:12 |
| olofk | No automatic interconnects. It's a huge task that I don't want to work on | 07:26 |
| olofk | But I've been improving the IP-XACT integration lately, and I think the best solution would be to let an external IP-XACT tool do this instead | 07:26 |
| olofk | I have a proof-of-concept on github where I have made IP-XACT models for some of the common IP cores, used Kactus2 to connect and generate a top-level and the read the IP-XACT files in FuseSoC to build the bitstream | 07:27 |
| ZipCPU|Laptop | Well, I can dream still. | 07:27 |
| olofk | Yeah, it's a nice dream. I've been having it too | 07:28 |
| ZipCPU|Laptop | Let me know if there's anything you need, support wise, from me for any of the cores I have put together. | 07:28 |
| ZipCPU|Laptop | I imagine someone's been using the real-time clock core and the quad-spi flash core, given the number of downloads those tend to receive. | 07:29 |
| olofk | Is OpenCores svn down again? | 07:50 |
| olofk | ZipCPU|Laptop: Do you have zipcpu somewhere else? I wouldn't recommend keeping stuff on OpenCores any longer :) | 07:50 |
| ZipCPU|Laptop | I have a master directory that I post from, why? | 07:51 |
| olofk | Just that the access to OpenCores is getting less reliable over time | 07:51 |
| olofk | Just tried to update my clone of zipcpu, but couldn't access opencores | 07:52 |
| ZipCPU|Laptop | Using the web interface, I'm pulling a _latest.tar.gz file now. | 07:54 |
| ZipCPU|Laptop | I can also do an svn diff without problems. | 07:55 |
| olofk | ZipCPU|Laptop: Think the issue was on my side | 08:00 |
| olofk | ZipCPU|Laptop: http://626bffb412fe41f4.paste.se/ | 08:11 |
| olofk | I also did these changes http://81dbb1b1a881ddfe.paste.se/ | 08:13 |
| Dan__ | Looking into it. | 08:16 |
| Dan__ | Good catch on the "r_pipe" change. I've been putting all of my time into the C6SoC version, that the changes necessary to make that work haven't guaranteed that the pipelined version still works. | 08:19 |
| olofk | Dan__: Another part that we are working on with FuseSoC is continous integration, so that regression tests can be run automatically :) | 08:21 |
| Dan__ | <Grins> | 08:21 |
| Dan__ | olofk: Fixed, and made your change as well. | 08:24 |
| olofk | Dan__: Cool. Thanks. Did you push it to SVN? | 08:32 |
| Dan__ | Yes, and without a problem either. :) | 08:33 |
| olofk | :) | 08:33 |
| shorne | Dan__: re: access to memory, yes the sim has a virtual memory and gdb can write to it pretty easy. since its in the same process | 08:38 |
| Dan__ | Fascinating. Your access to information within the Sim isn't the same as the access to the CPU when in hardware? | 08:39 |
| shorne | wallento: yes as franck said, its like that for most processors. some have some extra implementation, if its multiple cpus whichever cpu hits the breakpoint returns control to gdb with the cpu id which hit the breakpoint | 08:39 |
| shorne | Dan__: the api would be the same. Its just a bit easier for the target_ops is implemented here https://github.com/openrisc/binutils-gdb/blob/or1k/gdb/remote-sim.c#L1326 | 08:43 |
| shorne | gdbsim_ops.to_insert_breakpoint = memory_insert_breakpoint; | 08:43 |
| shorne | you can trace that down to default_memory_insert_breakpoint (in target-mem.c) | 08:45 |
| Dan__ | shorne: I see it, and I get it. It's just that, using Verilator, I've had a touch of a different experience. | 08:45 |
| Dan__ | Specifically, I've had to build and debug an interface to the hardware using the simulator, so my "simulator" interface often ends up being identical to the hardware interface. | 08:46 |
| shorne | sorry, its in mem-break.c, but if you follow it back its target_ops->to_xfer_partial | 08:52 |
| shorne | which is implemented at low level by the libsim.a method (sim_write) | 08:53 |
| shorne | yeah, its pretty easy to trace, and the sim is not built as complicated as real hardware | 08:57 |
| shorne | for gdb, there are actually 3 different ways to debug openrisc | 08:57 |
| shorne | 1. or1k - this cgen simulator contained 100% in gdb source tree | 08:58 |
| shorne | 2. or1ksim - the original openrisc simulator which is wrapped to provide libsim.a which satisfies the remote-sim requirements | 08:59 |
| shorne | 3. remote - which is socket based and can connect to an or1ksim process, openocd process which may be connected to real hardware | 09:00 |
| shorne | Dan__: I would guess you would do something similar to 3? or are you doing something else completely? | 09:00 |
| shorne | Dan__: I see verilator (I read something else) is your verilator run in gdb process i.e. through a lib? or you connect via some sockets? | 09:03 |
| shorne | did you read much of this? "gdb porting" http://www.embecosm.com/appnotes/ean3/embecosm-howto-gdb-porting-ean3-issue-2.pdf | 09:08 |
| Dan__ | shorne: Sorry ... stepped away there for a moment. | 10:03 |
| Dan__ | First, up front: I have not ported gdb to the ZipCPU. The experience I am citing is not from gdb, but rather from trying to roll my own debugger. | 10:04 |
| Dan__ | Second, I have (yet) to run a Verilator process from within gdb. Perhaps I should've--it might've helped trace some problems, but I haven't. I'm a firm believer in debug by printf until it doesn't work, and it seems to work nicely in Verilator. | 10:05 |
| Dan__ | My favorite means of debugging is via sockets. I forward my connection to a computer that is either connected to my hardware, or connected to a Verilator program. | 10:06 |
| Dan__ | The program connecting over the sockets uses the same interface specification as if it were connecting to the real hardware, and doesn't know any different. | 10:06 |
| Dan__ | To switch from connecting to sockets to connecting to the real hardware, I just switch the connection protocol. | 10:07 |
| Dan__ | This is fairly easy when the connection protocol goes over a serial port. Crossing from socket streams to serial port connection requires a little logic, but not that much. | 10:07 |
| shorne | Dan__: thats cool, definitely with the socket/serial command interface the target can be either software or real hardware | 10:09 |
| shorne | thats a bit how the gdb remote works | 10:09 |
| shorne | but you are writing your own debugger | 10:10 |
| Dan__ | Finally, as I think I said on the ZipCPU homepage on opencores, "I am envious of what [the OpenRISC team] has accomplished." | 10:10 |
| Dan__ | Yes, I've been writing my own debugger. It is nowhere near as fully featured as gdb is, and at some point I will probably switch to gdb. | 10:10 |
| Dan__ | I can "step" through my code, and I can stop on breakpoints, but I don't have my own debugger to the point where it 1) matches assembly to C code, or 2) can restart the program following a breakpoint. | 10:11 |
| shorne | Do you use gdb as a reference? | 10:11 |
| Dan__ | Oh, and neither can I print out variables by symbol name. | 10:12 |
| Dan__ | No, I have not. I probably will soon, but I have not. | 10:12 |
| Dan__ | Understand my process: when it was easier to build my own assembler, I did so. It was easier to do so than to integrate with binutils. | 10:15 |
| Dan__ | I have since figured out binutils, and integrated into it. I also have a GCC backend which is (mostly) working. | 10:16 |
| Dan__ | I still don't have newlib running. | 10:16 |
| Dan__ | gdb is ... a step beyond where I am at. What I have instead is my own, whipped up, debugger that has gotten me this far. | 10:17 |
| olofk | Dan__: One thing I would recommend is to piggy-back on the debug interface (i.e. adv_debug_sys). That way you'll be able to connect OpenOCD and gdb without trouble. It will also work against a running verilated model | 10:18 |
| shorne | I see, pretty cool. I had a look at gcc backend, that lisp dialect was a bit of a monster | 10:18 |
| Dan__ | olofk: It will be easier to piggy back on an interface if there is someone I can ask questions of as I go along. Perhaps this is a forum where I can find such answers? | 10:19 |
| olofk | Dan__: You've come to the right place :) | 10:19 |
| Dan__ | Thank you. | 10:19 |
| Dan__ | shorne: As for that lisp dialect, yes it is quite the monster. I've been slicing through it one piece at a time. | 10:20 |
| Dan__ | Perhaps only one scale at a time. | 10:20 |
| shorne | haha | 10:21 |
| Dan__ | Oh, and the other thing about the debug interface that's going to be ... an adventure. The smallest addressable unit on the ZipCPU is 32-bits. | 10:21 |
| Dan__ | I'm not looking forward to handling the porting of the debug/symbol information from character streams to that 32-bit format. | 10:21 |
| Dan__ | The real adventure I am currently involved in is to try to port a ZipCPU to the CmodS6--a Spartan-6 LX4. It's a *really* small chip. | 10:27 |
| Dan__ | It's so small, I couldn't fit the interface to the debugger. | 10:28 |
| Dan__ | Neither could I fit the interface to command the read/write of memory from an external port. | 10:29 |
| Dan__ | Further, although there is a Verilator model of the board I'm using, the model doesn't simulate all of the hardware the board has or has hooked up to it. (buttons, keypad, LCD, audio, etc.) | 10:31 |
| --- Log closed Tue May 10 00:00:59 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!