TCF support advanced

[davekeeshan]

I am trying to get Eclipse to debug into a working design I have. I have followed the instructions for TCF installation, and it appears to successful, at least on the PC side.

I have a a7-100 with a rocket64b1 and it does not connect. I have downloaded the bitstream from the release area and I have built my own image. They are working images and I have the bare metal hello world working (a7 have issues booting into linux at the moment, #131, different problem)

If I look at the design the bscan does not seem to be enabled, and I don't know how to enable it, what am I missing and what do I need to change?_

[eugene-tarassov]

Do you have hw_server running? You should be able to connect to the server even without a board.

[davekeeshan]

Yes I have it running too, I saw it appear in eclipse, but when I connect to it nothing was hanging off it. Do I need the start xsdb as well?

I have used it in vitis with a microblaze and it's mdm and I have been able to connect to that in the same board. But that manages the xsdb itself.

[eugene-tarassov]

No, you don't have to run xsdb. xsdb can launch hw_server if it is not already running, and xsdb can be used simultaneously with Eclipse, but it is not required. As long as you have hw_server and a board connected to same machine, you should see at least FPGA node in the Debug view in Eclipse. Make sure you have only one hw_server running on the machine to avoid connecting to a wrong one.

[davekeeshan]

Is it possible that there is just no debug core enabled in the a7-100t release? When I download the bitstream from the release area and program the board I have, it gives me the warning, before I do any thing else:

WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution: 
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device.  To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).

When I open the implementation of the the design I generated locally (because you can't do this test on a bitstream) and run the command:

get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]

I get this:

WARNING: [Vivado 12-750] There are no ChipScope debug cores in this design.
ERROR: [Common 17-55] 'get_property' expects at least one object.
Resolution: If [get_<value>] was used to populate the object, check to make sure this command returns at least one valid object.

Also when I open the design and drill down into where the jtag is defined, JtagSeries7. In the vhdl I see the BSCANE2 and the associated BUFG, but when one looks at the design hierarchy, on the left, they do not appear. All that is present are the synchronizers

That one alone is a bit baffling for me, I have seen blocks before in vivado being added and dropped out via generics, but even dropped out of the design they are still present in the hierarchy, but greyed out, the absence totally is a new one I would like to understand on its own.

[eugene-tarassov]

ChipScope debug cores are parts of Vivado logic analyzer. It is used to debug RTL: see waveforms of selected signals, etc. It is totally unrelated to xsdb, Eclipse or software debugging. Let's step back, you said "when I connect to it nothing was hanging off it". This is wrong, even with empty, unprogrammed FPGA you should see something hanging off it.

First, try to run xsdb and enter connect and targets commands:

You should see at least one target: xc7a100t - the FPGA.

Don't disconnect xsdb, open Debug Configurations in Eclipse, you should see Xilinx Hardware Server in the Available Targets list:

Click the Debug button, and you should see xc7a100t hanging off the Hardware Server:

You need to get these step working before you can do anything with a design.

[eugene-tarassov]

I do however have the release image loaded, so how do I find the riscv under that.

This is strange. If I load bitstream I immediately see RISC-V:

xsdb% ta
  1  xc7a100t
xsdb% ta 1
xsdb% fpga m:/jenkins/releases/riscv-fpga/riscv-2022.2-arty-a7-100t-64b1.bit
100%    2MB   1.8MB/s  00:01
xsdb% ta
  1* xc7a100t
     2  RISC-V
        3  Hart #0 (Running)
xsdb%

And it shows up in Eclipse too:

Are you building the bitstream images on windows or linux?

I use both Windows and Linux. I can build bitstream on both without issues. In general, I prefer to run scripts on Linux, and run GUI on Windows.

[davekeeshan]

OK based on some of the feedback here, I jumped over to windows. With windows, hw_server and eclipse I can get exactly what you see above. Given the makeflow is so linux dominated, it did not occur to me to look over there until I saw the images on windows.

Moving on from that, I was able to go back to linux, into eclipse and point the TCF at the windows machine, still running the same hw_sever, and it too was able to show me the design down to Hart #0

So I am having problems with a full linux setup. It is either there is something wrong with TCF -> hw_server integration on linux, or there is something wrong with TCF -> hw_server on my machine. On the same machine, I have been able to run a full program under microblaze, with MDM and breakpoints, so there is some kind of working connectivity.

I will dust off another linux machine and see if that one works.

So that is all a huge step forward, thank you for answering my questions so far, this whole area brings together a massive collection of disciplines is is hard to stitch them all together.

Some notes, when on windows, using xsdb for debug, I did not get the same thing you did, this was my output (The bitstream is the one from the release area not the one I generated):

xsdb% connect
tcfchan#0
xsdb% ta
  1  xc7a100t
     2  MicroBlaze Debug Module at USER2
        3  MicroBlaze #0 (Running)
xsdb% fpga riscv-arty-a7-100t.bit
100%    2MB   1.8MB/s  00:01
xsdb% ta
  1  xc7a100t
     2  MicroBlaze Debug Module at USER2

No RISC-V or Hart, however when I run this on linux, I only get xc7a100t. However as I said above, when eclipse connects in, it does see the the full design down to Hart #0.

My next step is to attempt to compile the bare metal and download it to the board, ideally with the ability to set breakpoints. There is not much information on this page to detail that, are you aware of any relevant documentation or tutorial to learn from?

[davekeeshan]

I made some progress here myself.

As the build environment is linux only (and linux can't see windows mounts and vice versa), I was trying to get the elf to come from linux eclipse. To download an elf to the Hart #0 one needs to add the linkage from the elf file to the hart in Download section of the 'Edit Configuration'

(This is what works eventually)

After I loaded the release bitstream on to the fpga, I could not get the elf to download and run successfully on linux.

I then copied the elf back to windows and I could not get the elf to download and run there either.

After reviewing the readme, I decided to check with the xsdb path. I was able to get the xdsb to download the the elf file, and while it did not work immediately. When I exit xsdb, the program contained in the elf starts to run.

connect
fpga riscv-arty-a7-100t.bit
targets -set -filter {name =~ "Hart #0*"}
dow -clear boot64.elf

(boot64.elf is just the 64 bit version of hello world)

After this I stop xsdb and start hw_server.

Now when I connect from eclipse (both from windows and linux) I am now able to download and run new elf files to the board and they now work correctly. It is not clear to me what xsdb is getting unstuck.

If I reload the release bitstream onto the fpga, I am back to square one and I can't download elf files from windows or linux in eclipse.

I still don't know how to set breakpoints.

[eugene-tarassov]

So I am having problems with a full linux setup.

Have you installed JTAG cable drivers? See Installing-Cable-Drivers

I did not get the same thing you did, this was my output

So you have MicroBlaze design loaded, and if you re-program FPGA with RISC-V, the debugger still shows MicroBlaze. It can be a bug: the debugger fails to detect changes in FPGA contents. A workaround is to start with empty FPGA, if MicroBlaze flushed on the board - removed the jumper that enables the flush, or erase the flush.

My next step is to attempt to compile the bare metal and download it to the board, ideally with the ability to set breakpoints. There is not much information on this page to detail that, are you aware of any relevant documentation or tutorial to learn from?

There are tons of debugger docs on the AMD/Xilinx website, but you already know how to debug MicroBlaze, RISC-V debugging is same.

[eugene-tarassov]

To download an elf to the Hart #0 one needs to add the linkage from the elf file to the hart in Download section of the 'Edit Configuration'

In the dialog box, you need to check "Set PC to program entry address"

[davekeeshan]

In the dialog box, you need to check "Set PC to program entry address"

Yes! Thank you. There are so many toggles and radio buttons it can be a bit bamboozling which is and isn't important.

Have you installed JTAG cable drivers?

I thought I had, that they had been installed as part of the vivado install process, which is usually where they always came in for me in the past, though the current version of vivado install is locking up during install, is that hang happening before the JTAG cable drivers getting installed? (Rhetorical question)

I have been on so many computers in the past few months it may have fallen through the gaps. I didn't see any issues before this because the more pure bitstreams download tasks work with out issues (this this is probably exactly why the full cable drivers need to be installed.)

Any way, I now see a fully working flow happening on linux now, with working breakpoints too, so that is a huge step forward for me, thanks!

It can be a bug: the debugger fails to detect changes in FPGA contents

Yes that makes sense to me. That can be annoying, but not a blocker.