Issues building/running Ibex Demo System on Arty35

[LMC53]

I had to resolve two issues while trying to get the Ibex Demo System running on my Arty35 board, following the steps in the Readme.md; I hope the following will save time for anyone else who tries this, and can be incorporated into the Readme.md via an appropriate update.

First Issue: the FPGA bitstream built via FuseSoC absolutely wasn't talking to OpenOCD at all. Explanation: the debug module was not being built correctly, because the FuseSoC installed via the python_requirements.txt file doesn't allow for a 'Flags' item in a 'Target' section within a .core file. This causes incorrect fileset selection for the Debug module: the Arty build needs to read the flag 'use_bscane2_tap' as True, but with 'Flags' unrecognised that's not happening. A quick workaround is simply to tweak the .core file so it selects unconditionally the fileset containing the bscane tap module. A cleaner resolution for the long term probably needs to be decided by a maintainer of the lowRISC fusesoc repo who knows how the various branches are being used, but here's the gist of the problem: the file fusesoc/capi2/core.py creates the Core() class from the string 'description', and there's a crucial difference between the OT and Main branches: in Main, the Target section is defined to allow an entry with name 'flags' at line 799, within .dicts; by contrast, in OT, the Target section does not have any .dicts at all, and doesn't have 'flags' in .members or .lists either - hence the rejection of the keyword 'flags'. Options would include (a) updating python_requirements.txt to select Main branch rather than OT, IF that would work - haven't tried it (b) updating the OT capi2/core.py file to add the missing 'flags' entry IF that doesn't break things for someone else(c) some other solution.

Second Issue: The script used to run the demo program uses an option set_prefer_sba which is not known to OpenOCD v.012, and appears to make that tool get stuck in and endless loop while communicating with Arty via JTAG. A comment in the source repo says this option is now deprecated, so I tried simply commenting it out, and confirmed this lets the demo run successfully.

[Stycore]

I think I'm having the same issue, where are you getting the bscane module fileset to include in the .core?

[LMC53]

If you take a look in pulp_riscv_dbg.core, it shows the flag is supposed to do a pretty simple job. In the targets section, lines 45-46 bring in either "files_xilinx_bscane_tap" (this is the selection you want) or "files_jtag_tap" (this is the selection you're probably getting). Both of those filesets are defined just a little way back in the same .core file, starting at lines 25 and 30 respectively: all that really needs to happen is to choose vendor/pulp_riscv_dbg/src/dmi_bscane_tap.sv rather than vendor/pulp_riscv_dbg/src/dmi_jtag_tap.sv

My quick fix was to edit line 45 so it just reads "files_xilinx_bscane_tap", knocking out the flag check, and to comment out line 46 entirely (because I'm not creating an ASIC).

Hope that gets it working for you; good luck!

[Stycore]

Was looking at the wrong .core; this worked, thanks!

[LMC53]

Good to hear it's working; congrats! :)

[marnovandermaas]

Thanks for noting these issues @LMC53! As you say the first issue would be fixed if we upstream our fusesoc changes, this is on our radar but won't happen imminently. The second issue should probably be changed in the script, would you like to make a PR for that?

[LMC53]

PR for the second issue created now. For the first issue, understanding that upstreaming the OT changes for FuseSoC is not something that can happen quickly/easily, an interim solution would be to offer two versions of ibex-demo-system.core: one for Arty, one for CW305. The idea is simply that since OT FuseSoC doesn't (yet) support automatic selection of the appropriate JTAG file via a flag setting, a user can just make the selection manually by choosing the .core file that matches their preferred target. If this makes sense, I can do another PR.

[paulcobb27]

Sorry: that previous comment included a slight confusion on my part about which of the existing synth targets in ibex-demo-system.core try to select the xilinx flavour of the debug module.

Just to be clear: all the synth targets that currently try to employ the flag 'use_bscane_tap' could instead use a version of ibex-demo-system.core that unconditionally selects the fileset 'files_xilinx_bscane_tap', while any synth target (currently only synth_sonata) that does not set the flag could use an alternative version of the.core that unconditionally selects the fileset 'files_jtag_tap'.

Of course this usage could be made clear in an update to the Readme.md