[Open SoC Debug] Queries Regarding GSoC and Open SoC

Anant Sharma anant16129 at iiitd.ac.in
Wed Feb 28 14:42:17 CET 2018


Hi,

I am getting the following error when I m trying to build and run verilator
simulation of a compute tile. PFA the log file. I have created the
variables OPTISOC_SOURCE and FUSESOC_CORES and it is still not working out.
Any advise?

Thanks,

Anant

Anant Sharma,
2016129,
BTech - ECE,
IIIT Delhi,

Ph: 9718827023

On Mon, Feb 26, 2018 at 1:33 AM, Philipp Wagner <philipp.wagner at tum.de>
wrote:

> Hi Anant,
>
> great to hear that you were successful!
>
> Am 25.02.2018 um 19:00 schrieb Anant Sharma:
> > I have set up my environment and ready to go. I faced a little problem
> > because my system couldn't find or1k-elf-gcc, but I kind of fixed it. (I
> > don't think there's anything wrong with the python script).
>
> Did you source the setup_prebuilt.sh script which comes as part of the
> prebuilts?
>
> > Also, went
> > through the examples of the Verilator. I am all set. What can I do next?
>
> Great. By trying out OpTiMSoC you saw the hardware in which the
> run-control debug/GDB support should be integrated.
>
> Now is a good time to look at the other side: how GDB actually talks to
> a processor. That part is in fact easier than one might guess: the
> processor core simply provides an interface with special-purpose
> registers. By reading and writing these registers the CPU can be
> stopped, breakpoints can be set, etc. The documentation for this
> functionality is part of the OR1k architecture specification
> (https://github.com/openrisc/doc/blob/master/openrisc-arch-1.2-rev0.pdf,
> Chapter 11).
>
> To access the registers mentioned in the or1k specification the mor1kx
> CPU core has dedicated ports. You can find them here:
> https://github.com/openrisc/mor1kx/blob/master/rtl/verilog/mor1kx.v#L139
> (starting with "du_").
>
> What we're skipping for now is the question how the GDB software can
> talk to the hardware. That part differs between simulation and real
> hardware, and also different in traditional debug systems (which make
> use of JTAG) and the one we're trying to build.
>
> So back to the debug interface of the processor. To see that interface
> in action, you could try your first hardware modification.
>
> - Take the simplest example in OpTiMSoC, the compute_tile_dm with a
> single core running in Verilator. You have already built that design
> when working through the tutorial. However, now you need to re-build it
> frequently. To do so make use of fusesoc directly as it is documented
> here: https://www.optimsoc.org/docs/master/user_guide/develop.html
>
> - Enable the debug unit in the CPU by adding
> FEATURE_DEBUGUNIT("ENABLED") to the mor1kx_module file.
>
> - You can now try to add Verilog code to stimulate the debug port. Since
> we're just experimenting, you can add the code for example into the
> mor1kx_module file. You could try to do the following: After the reset
> of the CPU, configure it through the debug port to have a breakpoint set
> when entering the main function. You do this by using the du_* signals
> as outlined in the or1k specification.
>
> Breakpoints are always set to a given program counter, so to break at
> the main function you need to know the program counter at this point.
> You can find it by taking a look at the disassembly of the program
> you're running on the mor1kx core. If you use the hello.elf file for
> example (as in the tutorial), you can determine the program counter as
> follows:
>
> ~/src/baremetal-apps/hello $ grep '<main>:' hello.dis
> 00002540 <main>:
>
> In my case the program counter when entering the main function would be
> 0x2540. This could differ on your machine though, so make sure to check
> yourself.
>
> - Once you have made the necessary modifications in the Verilog code,
> you can re-run the simulation. Run it with waveforms enabled and have a
> look at them in Gtkwave. Does the CPU stop indeed when the breakpoint is
> hit?
>
>
>
> I know it's a lot to wrap your head around. Good luck and persistence!
> If you have questions, please let us know.
>
> Best,
>
> Philipp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/opensocdebug/attachments/20180228/5b427042/attachment.html>
-------------- next part --------------
WARNING: Unknown item "top_module" in section "xsim" in /home/anant3110/optimsoc/examples/fpga/nexys4ddr/system_2x2_cccc/system_2x2_cccc_nexys4ddr.core
WARNING: Unknown item "part" in section "xsim" in /home/anant3110/optimsoc/examples/fpga/nexys4ddr/system_2x2_cccc/system_2x2_cccc_nexys4ddr.core
WARNING: Unknown item "top_module" in section "xsim" in /home/anant3110/optimsoc/examples/fpga/nexys4ddr/compute_tile/compute_tile_nexys4ddr.core
WARNING: Unknown item "part" in section "xsim" in /home/anant3110/optimsoc/examples/fpga/nexys4ddr/compute_tile/compute_tile_nexys4ddr.core
WARNING: Unknown item "top_module" in section "xsim" in /home/anant3110/optimsoc/examples/sim/system_2x2_cccc/system_2x2_cccc_sim.core
WARNING: Unknown item "top_module" in section "xsim" in /home/anant3110/optimsoc/examples/sim/compute_tile/compute_tile_sim.core
ERROR: Conflicting requirements:
Requirements: 'optimsoc_examples_compute_tile_sim == 0-0' <- 'glip_backend_tcp >= 0-0'
    +optimsoc_examples_compute_tile_sim-0-0 was ignored because it depends on missing packages
Requirements: 'optimsoc_examples_compute_tile_sim == 0-0'
    Install command rule (+optimsoc_examples_compute_tile_sim-0-0)

Failed to resolve dependencies for optimsoc:examples:compute_tile_sim


More information about the OpenSoCDebug mailing list