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

[heliosfa]

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.

This issue has just bitten me while adding some board support. This could really do with a note in the README that the version of FuseSoC installed in the native environment has this issue.

[medexs]

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.

This issue has just bitten me while adding some board support. This could really do with a note in the README that the version of FuseSoC installed in the native environment has this issue.

I agree, ran into the same problems myself when adding a support for Digilent Basys 3 board.

[marnovandermaas]

This issue has just bitten me while adding some board support. This could really do with a note in the README that the version of FuseSoC installed in the native environment has this issue.

Thank you so much for raising this issue. I would be happy to have a note in the README regarding this. Would any of you mind writing the text that would have stopped you from having the confusion and putting it in a PR?

[heliosfa]

Thank you so much for raising this issue. I would be happy to have a note in the README regarding this. Would any of you mind writing the text that would have stopped you from having the confusion and putting it in a PR?

More than happy to when I’m back in the office.

One alternative though would be to default to using the bscane_tap as presumably the majority of people will be using this on an FPGA? That way the tags issue affects fewer targets and can then be mentioned in the readme. What are your thoughts on this?

[marnovandermaas]

Yes, maybe that's better. The only reason we don't use the bscane_tap everywhere is for Sonata, but I can make sure Sonata stays working while by default doing the right thing for the other boards.

[heliosfa]

I've made an attempt at a PR to flip that logic around. The README may want some tweaking, but it gets the point across.

I've tested this in-hardware on the Blackboard as that's what I've got at home at the moment. I've build the bitstreams for the other non-Sonata platforms and checked that they are all using dmi_bscane_tap.sv rather than dmi_jtag_tap.sv.

[marnovandermaas]

Ok, I think this is now solved by merging #137 Please feel free to reopen this if it doesn't.