| --- Log opened Fri Jul 21 00:00:23 2017 | ||
| mithro | Do people have thoughts on https://github.com/SpinalHDL/VexRiscv ? | 00:15 |
|---|---|---|
| mithro | Heyo imphil & wallento | 09:13 |
| imphil | mithro, hi | 09:14 |
| mithro | So at the moment we are getting random lock ups of code running on the or1k and I'm trying to track down what is going on. | 09:15 |
| mithro | imphil: My current theory is some type of memory corruption is going on | 09:17 |
| mithro | Which is causing the processor to go into the exception state... | 09:18 |
| mithro | I'm about to connect our virtual scope up the the processor, but thought I would see if there was something that the soc debug could give us | 09:18 |
| imphil | probably a function trace (calls/returns of functions) could reveal a bit. that's working rather well in OSD. What also could help is to put a trace point in the exception handlers of the kernel | 09:21 |
| imphil | but if you need a quick and dirty solution to get your problem out of the way, chipscope and friends are probably the fastest way to see where the execution stops | 09:23 |
| mithro | yeah | 09:24 |
| mithro | I mean gdb debugging would be general good, so if I can kill two birds with one stone | 09:24 |
| mithro | specially for the linux bring up as it gets further along | 09:25 |
| mithro | imphil: So how would I "integrate" your stuff? | 09:26 |
| imphil | in this case I'd probably go ahead and integrate OSD, even though it doesn't support gdb for now. Working with traces and events isn't nice in some cases, but it should be able to do the job. And as soon as I get around to integrate the gdb stuff, you get that for free. | 09:27 |
| imphil | you mean how to get osd into litex? | 09:27 |
| mithro | imphil: Yeah | 09:31 |
| mithro | imphil: I assume I need to get some verilog and connect it up to the mor1k core and the uart in some way? | 09:32 |
| imphil | yeah. the most tricky part is usually the off-chip interface. which board are you targeting? | 09:33 |
| mithro | The Opsis, Atlys and MimasV2 | 09:34 |
| imphil | That increases the trickiness a bit possibly, as all others users are currently using Xilinx boards. However, it should be doable with reasonable effort. | 09:35 |
| mithro | imphil: What is the host interface? All the boards have a USB UART that I could connect to the core? | 09:36 |
| imphil | So. what do we need: (1) a off-chip interface. UART works fine and is implemented in a technology-agnostic way, so it should work well on Altera boards. | 09:36 |
| imphil | (2) some basic debug infrastructure: the debug interconnect (a couple of verilog modules implementing a ring NoC) together with the SCM and HIM modules | 09:37 |
| imphil | (3) the CTM (for trace) and STM (system trace, i.e. printf support) modules connected to the mor1kx core | 09:37 |
| imphil | (4) optional, the UART-DEM module connected to the bus imitating a UART device over the debug interconnect | 09:37 |
| imphil | a good reference implementation for what you're trying to do is the compute_tile example in optimsoc running on a Xilinx Nexys 4 ddr board. It's just a single mor1kx core and uses UART as off-chip interface | 09:39 |
| imphil | find the top-level file here: https://github.com/optimsoc/optimsoc/blob/master/examples/fpga/nexys4ddr/compute_tile/rtl/verilog/compute_tile_dm_nexys4.sv | 09:39 |
| mithro | So what is the compute_tile_dm ? | 09:40 |
| imphil | if you look there, https://github.com/optimsoc/optimsoc/blob/master/examples/fpga/nexys4ddr/compute_tile/rtl/verilog/compute_tile_dm_nexys4.sv#L147 the glip_uart_toplevel module is the off-chip interface from UART to a FIFO interface. the debug_interface module (https://github.com/optimsoc/optimsoc/blob/master/examples/fpga/nexys4ddr/compute_tile/rtl/verilog/compute_tile_dm_nexys4.sv#L181) contains the ring noc and the HIM (host | 09:42 |
| imphil | interface) and SCM (system control) modules. The ring connections are then passed through the hierarchy and in https://github.com/optimsoc/optimsoc/blob/master/src/soc/hw/compute_tile_dm/verilog/compute_tile_dm.sv#L321 the mor1kx core is connected to the CTM (core trace) and STM (system trace) modules | 09:42 |
| imphil | compute_tile_dm is a full system with just one mor1kx core, a wishbone bus and a memory, i.e. the most simple SoC you could imagine | 09:43 |
| mithro | So I think I need debug_interface, glip_uart_toplevel, osd_stm_mor1kx, osd_ctm_mor1kx | 09:46 |
| mithro | What is osd_mam_wb ? | 09:46 |
| imphil | memory access. it allows you to read and write a wishbone-attached memory from the host (e.g. to write software into it) | 09:48 |
| imphil | a general overview over all these modules is also available at http://opensocdebug.readthedocs.io/en/latest/01_overview/getting_started/index.html#osd-for-run-control-debugging | 09:48 |
| mithro | okay | 09:48 |
| imphil | I don't know how you do that right now, we use the MAM support always to load the software to the device | 09:49 |
| mithro | We use etherbone like thing | 09:50 |
| mithro | We also have a BIOS which can load via tftp etc | 09:50 |
| imphil | oh, that's nice :) | 09:51 |
| mithro | litescope == _florent_'s version of chipscope | 09:51 |
| imphil | so to get started, I'd start getting the off-chip interface up and running. for uart, it should be easy, but still constraint files are easy to mess up. Since OSD uses GLIP to encapsulate the off-chip interface, I'd recommend first getting a loopback example through UART running. | 09:53 |
| imphil | Get the GLIP source code, and start with this example: https://github.com/TUM-LIS/glip/tree/master/src/backend_uart/logic/demo/nexys4ddr and modify it to work for your board. It shouldn't be more than the constraint files and clocking. | 09:54 |
| imphil | if that works, you can add the debug_interface and the glip_toplevel_uart to your project and with only that you should already be able to connect to your board through the opensocdebug software. | 09:55 |
| imphil | if that's running everything else becomes much easier, since you now can add the other debug modules one by one and confirm they're working | 09:56 |
| mithro | okay | 10:01 |
| mithro | I already know all the pins for the uarts and stuff, we use them all the time | 10:01 |
| mithro | I think that gives me enough to go on | 10:03 |
| imphil | give it a try, and let me know if you have any problems. It's sometimes just small tiny things which prevent the system from working, and I think I've seen most of them by now :-) | 10:04 |
| mithro | yeah | 10:04 |
| mithro | Will hopefully get to it this weekend | 10:05 |
| imphil | and if you have a choice of USB UART, use the fastest one you can find. Especially for tracing bandwidth is king. | 10:05 |
| mithro | None of our uarts are particularly fast - we normally just use the GigE | 10:07 |
| --- Log closed Sat Jul 22 00:00:25 2017 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!