IRC logs for #openrisc Monday, 2016-05-09

--- Log opened Mon May 09 00:00:58 2016
olofkDan__: 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
olofkI've been meaning to take a closer look at ZipCPU. First intention would of course be to add FuseSoC support02:48
wallentoshorne: 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 trap04:51
wallentoah, got it04:51
wallentothanks _franck__04:52
wallentodid we have this before?04:53
_franck__https://github.com/ntfreak/openocd/blob/master/src/target/openrisc/or1k.c#L91504:53
wallentoI am wondering how this integrates with multicore then05:15
wallentobecause changing the code changes it for all, so the excpetion handler needs another criterion too, correct?05:16
ZipCPU|Laptopolofk: (From another IRC chat program ----) Yes, I am the "Dan" that has been trying to answer all the forum posts.05:27
ZipCPU|LaptopI just found that the forums got a touch too ... quiet.05:28
wallentowell formulated ;)05:39
olofkZipCPU|Laptop: Agree with wallento :) Much appreciated to have some life there, even though we have basically given up on OpenCores06:27
ZipCPU|LaptopWell gosh ... thanks!06:46
ZipCPU|LaptopMy biggest problem there is that there are so many questions I don't know how to answer.06:47
ZipCPU|LaptopMost 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|LaptopOnce 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|LaptopAs 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|LaptopFrom what I gather, it 1) replicates cores from servers into a project, and 2) manages building the interconnect for those same cores?06:50
olofkZipCPU|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 repo07:02
olofkIt 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 scripts07:02
ZipCPU|LaptopHow hard is it to make something fusesoc compatible?  Is it just the difficulty of building the .core file?07:03
olofkZipCPU|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 repo07:04
ZipCPU|Laptopolofk: 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
olofkSo 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
olofkZipCPU|Laptop: For simulation that is often enough07:06
ZipCPU|Laptopolofk: I have become a *big* fan of Verilator, and the flexibility it gives me.  Does FuseSoC support a Verilator "simulation"?07:07
olofkFor 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 thefile07:07
olofkZipCPU|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 system07:08
ZipCPU|Laptopolofk: 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
olofkZipCPU|Laptop: Yes :)07:10
olofkNothing fancy there. I'm trying to keep the FuseSoC part as thin as possible to support all user flows07:11
ZipCPU|LaptopThat's cool.  Every time I've done it to date it has always been by hand.07:11
ZipCPU|LaptopHave 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
olofkNo automatic interconnects. It's a huge task that I don't want to work on07:26
olofkBut 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 instead07:26
olofkI 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 bitstream07:27
ZipCPU|LaptopWell, I can dream still.07:27
olofkYeah, it's a nice dream. I've been having it too07:28
ZipCPU|LaptopLet me know if there's anything you need, support wise, from me for any of the cores I have put together.07:28
ZipCPU|LaptopI 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
olofkIs OpenCores svn down again?07:50
olofkZipCPU|Laptop: Do you have zipcpu somewhere else? I wouldn't recommend keeping stuff on OpenCores any longer :)07:50
ZipCPU|LaptopI have a master directory that I post from, why?07:51
olofkJust that the access to OpenCores is getting less reliable over time07:51
olofkJust tried to update my clone of zipcpu, but couldn't access opencores07:52
ZipCPU|LaptopUsing the web interface, I'm pulling a _latest.tar.gz file now.07:54
ZipCPU|LaptopI can also do an svn diff without problems.07:55
olofkZipCPU|Laptop: Think the issue was on my side08:00
olofkZipCPU|Laptop: http://626bffb412fe41f4.paste.se/08:11
olofkI 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
olofkDan__: 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
olofkDan__: Cool. Thanks. Did you push it to SVN?08:32
Dan__Yes, and without a problem either.  :)08:33
olofk:)08:33
shorneDan__: re: access to memory, yes the sim has a virtual memory and gdb can write to it pretty easy. since its in the same process08: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
shornewallento: 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 breakpoint08:39
shorneDan__: 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#L132608:43
shornegdbsim_ops.to_insert_breakpoint = memory_insert_breakpoint;08:43
shorneyou 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
shornesorry, its in mem-break.c, but if you follow it back its target_ops->to_xfer_partial08:52
shornewhich is implemented at low level by the libsim.a method (sim_write)08:53
shorneyeah, its pretty easy to trace, and the sim is not built as complicated as real hardware08:57
shornefor gdb, there are actually 3 different ways to debug openrisc08:57
shorne1. or1k - this cgen simulator contained 100% in gdb source tree08:58
shorne2. or1ksim - the original openrisc simulator which is wrapped to provide libsim.a which satisfies the remote-sim requirements08:59
shorne3. remote - which is socket based and can connect to an or1ksim process, openocd process which may be connected to real hardware09:00
shorneDan__: I would guess you would do something similar to 3? or are you doing something else completely?09:00
shorneDan__: 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
shornedid you read much of this? "gdb porting" http://www.embecosm.com/appnotes/ean3/embecosm-howto-gdb-porting-ean3-issue-2.pdf09: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
shorneDan__: thats cool, definitely with the socket/serial command interface the target can be either software or real hardware10:09
shornethats a bit how the gdb remote works10:09
shornebut you are writing your own debugger10: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
shorneDo 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
olofkDan__: 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 model10:18
shorneI see, pretty cool. I had a look at gcc backend, that lisp dialect was a bit of a monster10: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
olofkDan__: 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
shornehaha10: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!