A Quartus Pro backend

[GCHQDeveloper992]

I'm currently working on projects that use both Quartus Std and Quartus Pro. The Pro version of the tools have made a few changes around the tool executable names and how QSYS gets invoked - this makes it incompatible with the current FuseSoC backend.

You mentioned in issue #217 that you were hoping to move backends toward the Vivado style templates, so I was considering trying to put something like that together for Quartus Pro. Whilst thinking about it I started wondering about how similar a Std and a Pro backend would look - I think the differences would end up being minor, probably something the templating could handle in a similar way to Vivado's use of the "{% if has_vhdl2008 -%}".

Would you be happy with such an approach that performed some rough tool version identification in the backend (perhaps calling out to 'quartus_sh --version', defaulting to standard?), followed by an appropriate use of templates? Alternatively, would two distinct backends (perhaps with some shared code in a base class?) be cleaner, to avoid any direct dependency on tools? Given the incompatibilities between Std and Pro (QSYS files are not compatible between versions I believe), perhaps this second approach could be less risky?

[olofk]

Apologies for the late reply.

This was very interesting and you raise many good points. My first instinct is that It would likely be easiest to have a single backend with some runtime detection, but it will require some thinking about corner cases. Incompatible qsys files sounds like it could cause some headaches, but perhaps there's a way to scan the files to see which version they are intended for and warn the user for incompatibilities. I don't have access to Quartus Pro so I'm a bit limited in testing. If needed I can see if I can use the trial version

I have a question about the differences in tool invocation. I know that the ip-generate command that is used by the current quartus backend is superseded by qsys-generate. Could it be that they have finally removed ip-generate from Quartus now and all that would be required is to change the code to call qsys-generate instead (optionally with a fallback to ip-generate for really old Quartus versions)?

[GCHQDeveloper992]

Not a problem, I've not had a chance to look into this much myself yet! I do have a local branch which implements a separate QuartusPro backend, but I agree it would be nice to merge Std and Pro into one (I might tidy it up a bit and push it for discussion purposes).

The Qsys files could have a basic version detection performed on them - the newer Pro files contains the line 'tool="QsysPro"' as part of the XML structure, whilst the Std edition ones do not. Perhaps when the backend encounters a QSYS file, it could attempt to parse the basic XML data to see if the QsysPro line is specified? Assuming the backend also identifies the available quartus version then throwing some sort of exception on a mismatch should be possible (the current Quartus backend raises a RuntimeError for missing required options, so doing something similar for mismatched files should work).

Working through the implications of this, I think it might start touching on the thoughts @imphil had in issue #103 . Imagine a core that implemented an Arria 10 memory controller, including the interactions with the EMIF. The EMIF would probably come from a QSYS file (using the Arria 10 External Memory Interfaces library component), whilst a more user friendly interface might come from custom RTL. A user depending on this core's interface for their project may be using either Quartus Std or Quartus Pro, which would therefore require both a Std and a Pro QSYS implementation being available. I think CAPI2 has a use flags system to allow for conditional inclusion of filesets, so if a use flag existed for "QuartusPro" and "QuartusStd" then that would make this process very easy? You could further imagine a scenario where this interface proves useful to people on Xilinx devices, and that conditionally selecting the Xilinx equivalent of QSYS files might be necessary, whilst maintaining the RTL interface. Is this something that useflags currently supports?

On the tool invocation question - if you call ip-generate on Quartus Pro, you now get an error message "Error: ip-generate for Platform Designer in Quartus Pro is only available under acdstest resource.". The qsys-generate application seems to function a little differently as well, having far fewer options than the old ip-generate. For instance, in my example Makefile template I'm currently experimenting with, I'm using:

qsys: project
{% for qsys_file in src_files if qsys_file|qsys_file_filter %}
  qsys-generate {{ qsys_file|qsys_file_filter }} --synthesis=VERILOG --family={{ tool_options.family }} --part={{ tool_options.device }} --quartus-project=$(NAME)
{% endfor %}

The existing quartus backend supported calling ip-generate with many more options, including specifying output directories, but these seem to have gone as all generated files are now placed in a subdirectory next to the QSYS file itself as best as I can tell. As you suggest, calling qsys-generate when in "Pro" mode and falling back to ip-generate otherwise seems like it would work quite well. Using the jinja2 template work means that this would be very simple as well.

I'll try and get both standard and pro working in a single backend, but if you could give some guidance on how useflags might be used here that would be very helpful.

[olofk]

The Quartus Pro backend is now merged. There is likely still some improvements to be made, but we could revisit this when proper support for use flags is added