No pin assignment of JTAG_TAP for de0_nano

[zavax2005]

I couldn't find pin assignment of JTAG_TAP for de0_nano from orpsoc-cores/systems/de0_nano/data/pinmap.tcl. Does that mean I couldn't use OpenOCD to write program to RAM via JTAG?

This seems to explain the trouble I'm running into now:

• I was able to build de0_nano.sof with fusesoc build command.
• I was able to upload the bitstream to the de0_nano board using quartus_pgm command
• OpenOCD could connect to the board and or1k_elf_gdb also could connect to the OpenOCD.
• After I uploaded a sample LED blinking program through GDB, nothing happened on the board.

However

• In order to verify the LED blinking program is valid, I instead used a pre-built de0_nano_orconf2013.sof image from opencores.org. The same LED blinking program started to work on the board.

Did I miss anything during those steps, or am I completely wrong? Thanks in advance.

-Xueming

[olofk]

The OpenRISC debug system needs to connect to a JTAG controller in the FPGA. For some SoCs, we use the jtag_tap as a JTAG controller, and in those cases we need to connect to FPGA I/O pins. For the de0 nano SoC however, the debug system is connected to an internal Altera JTAG controller in the FPGA which is called altera_virtual_jtag here. This controller is connected to the dedicated JTAG pins on the FPGA (which is the same interface that is used for example by SignalTap). Therefore we don't need any specific pin mappings for the JTAG pins, as this is hard wired in the FPGA

On the de0 nano board, the dedicated FPGA JTAG pins are then connected to a chip which translates the JTAG commands to USB, using the USB Blaster protocol. It is this way we use to connect OpenOCD to the OpenRISC.

About your problem with not getting the LED blinker running, I have a theory why it's not working. When the CPU is started, it starts to execute the program that is stored in the built-in boot ROM. The default boot ROM for the de0_nano SoC is set up to load a program from the SPI Flash to memory and execute this. In your case, there probably isn't any program in the SPI Flash, and since I have not implemented a fallback mechanism, nothing at all happens.

If my theory is correct we could get around this by using another boot ROM that just tries to execute directly from RAM instead. With this boot ROM, you can connect to the CPU with a debugger, upload your program, and when you reset the CPU, it will execute.

Try building with fusesoc build de0_nano --bootrom_file=~/.local/share/orpsoc-cores/systems/de0_nano/sw/clear_r3_and_jump_to_0x100.vh and see if that helps.

A better long term solution would probably be to improve the default boot loader to execute from RAM if nothing is found in the SPI Flash. I'll try to fix that

[zavax2005]

Thanks Olofk. Finally got back to check on this, and it is working now! So you theory is correct.

I have a question here: what does --bootrom paramter actually do during the fusesoc building? Before I post the question here, I kind figured out that I needed to change the bootrom configuration from "spi_uimage_loader.vh" to "clear_r3_and_jump_to_0x100.vh". So I did manually on the file at orpsoc-cores/systems/de0_nano/rtl/verilog/orpsoc_top.v, but it didn't seem to work....but using your --bootrom_file parameter did work! Do you have any documentation regarding parameters I can pass to fusesoc for building?

The reason why I asked about JTAG_TAP pin configuration is Julius Baxter's project at https://github.com/juliusbaxter/mor1kx-dev-env. He had pin mapping for the JTAG_TAP on his configuration. And I was able to build ajd run everything following his tutorials.....

Thanks again!
-Xueming

[olofk]

Hmm... that's strange. Changing the bootrom parameter in orpsoc_top.v should work. Maybe it was just a typo? Did you check the synthesis log (<workspace>/build/de0_nano/bld-quartus/de0_nano.map.rpt) to see if Quartus failed to find the file?

For parameters in general, you can just run fusesoc build de0_nano --help to find all options that can be used when building the de0_nano target. Similarly, you can use fusesoc sim de0_nano --help to find all options that can be used for simulation

mor1kx-dev-env is very outdated and not used anymore. I'm not sure anyone remembers the reason behind some of the decisions in there anymore :)