How to best share code between projects in Quartus Prime Standard and Quartus Prime Pro ?

Question

This is a very long request and actually contains several Questions, however, they follow

a common theme, so I hope you do not mind me bunching them together.

We have a current and a future product. Coarsely, they consist of a processor system connected to signal processing hardware in FPGA, and C(++) firmware running on the processor.

The difference between the two products is:

- More signal processing hardware instances of the same type

- Some new signal processing features exclusively with the new product (after delivery to customers)

We use FPGAs to be able to implement new features after product delivery.

As we were already using the Cyclone IV FPGA, it seems to make sense to use another Intel FPGA

to be able to share code between the two products. So we decided to use the Arria 10 for the new

product; and here begins my sadness:$

I thought we could easily share code, because both FPGAs are supported by Quartus Prime. But in

reality, the Cyclone IV is only supported by Quartus standard, but the Arria 10 is only properly

supported by Quartus Pro (correct me if I am wrong).

It seems that I have to migrate our Pro product to the Pro tools, and to prepare for this,

I would like to ask your opinion about three issues:

- QSYS compatibility (I use QSYS for whatever it is called these days)

- VHDL language compatibility

- C(++) language compatibility

QSYS compatibility

==================

The configuration files for code generation with QSYS is not compatible between the two versions.

For the processor system, this is not a problem, the two versions are sufficiently different to

not share FPGA code, and will probably not often be changed anyway.

However, for Signal Processing components (Fir filter, nco) generated by QSYS, this seems to be a problem.

## Question 1:

Is it possible to use the same QSYS files in both Quartus versions (in this case), or

is there any other way to share these between our product variants ?

VHDL language compatibility

===========================

This part is just to get Intel PSG to move in the right direction.

As long as we want to share code, it seems to be impossible to use any VHDL2008 language features

that I would like to use. In particular, I think fixed point arithmetic would be very useful for

signal processing. However, it seems the IEEE_proposed library is not compatible with the

preliminary VHDL2008 implementation in Quartus Standard.

This seems to mean that you can either:

- Only use the VHDL2008 features that are implemented in Quartus Standard (which features are those anyhow?)

- Only use the fixed point package (I assume it is possible to include the IEEE_proposed fixed point library in the Standard project, and the VHDL2008 fixed point library in the Pro project)

## Question 2

Is this correct ?

C(++) language compatibility

============================

The firmware library should be portable between the systems. However also here, the Quartus

Standard version is not further developed. However, here there seems to be something we can do:

It seems that the Nios II SBT for Pro can also be used FPGA hardware generated by Standard

software. However, for some reason, Intel PSG does not apply the Pro updates to the Standard

software.

##Question 3

If you have a license for the Pro software, is there anything that should you from using the Pro

SBT tools for the FPGA code generated by the Standard software?

What reason could Intel PSG have for not supporting this ?

Appeal to Intel PSG

===================

I have not experience with competing FPGA products, but from what I read in other newsgroups,

these are even worse in this respect. Nevertheless, Intel PSG, as your loyal customer I wish you

to outshine your competitors, and in doing so, make me happy:

I expect that support of a product is more than fixing bugs only. I think it also includes

porting tools to new operating system versions and supporting new version of the language

standards.

If you would do this, existing customers will be inclined to subscribe the support package.

I also would like to have IP in generic, standard compatible, portable code, no in generated

code that breaks with every package update.

Think of the four i-s ! (in compatibiliti)

tricky · Answer

For VHDL: Quartus prime has some limited 2008 compatability. The IEEE_proposed library you mention is NOT part of the VHDL standard. That library name was used when David bishop created '93 compatible versions of the VHDL 2008 libraries, and made versions for each of the synth tools of the time (circa 2007 - so this code is 11 years old now!). You should be fine using it in Prime standard, you just have to include the code in your project and compile it like any other file. I was using it just fine 10 years ago.

As for what is supported:

In Pro: "Full" VHDL 2008 support

Prime Standard: https://www.intel.com/content/www/us/en/programmable/quartushelp/15.0/mergedProjects/hdl/vhdl/vhdl_list_2008_vhdl_support.htm

(basically, not a lot, and this is unlikely to change)

TBH, most 2008 features that are useful in synthesis can be done '93 code without too much difficulty. You have the '93 versions of the fixed_point libraries i mention above, and the supported features are mostly just ways to make the code a little less verbose. The truely new features come for testbenches and verification, which isnt supported in Quartus anyway. 3rd party simulators (like modelsim) have good VHDL 2008 support for these features.

sstrell · Answer

Arria 10 is actually the only device family that is supported in both Standard and Pro. I don't see why you need to move to Pro given you're already used to Standard.

For Qsys (now called Platform Designer), a .qsys file from the Standard edition can be brought into Pro, but it will be converted and cannot be used again in Standard.

As for VHDL, yes, there is better VHDL2008 compatibility in Pro. To learn all the details about the differences, see the online training (it's not called Spectra-Q anymore, but all the info in there is still valid):

https://www.intel.com/content/www/us/en/programmable/support/training/course/osynqpro.html

So based on your questions, the only reason I see where you would have to move to Pro is if you need the VHDL 2008 compatibility. Otherwise, you can continue using Standard.

schendel_nsf · Answer

Thanks for your confirmation of my suspicion.

Before I continue complaining, I guess I will have to bring some examples of why I think VHDL2008 is superior to 93 for synthesis, and why I think Pro is really better than Standard for Arria 10 (apart from the fact that Intel does not recommend using the Standard version for Arria10 designs)

Unfortunately, no one commented on the SBT tools, and how to get support for the current version of C++.

I will have you know that I am the laughing stock of my C++ programming colleagues when I tell them, that it is recommended practice to continue to use the language version of '93 (I consider you to be an exepert). I guess I can counter that with saying that a properly designed high-level language does not need to be redesigned every three years, but I ma not sure if that argument will carry the day. 😉

(Look we can post smileys with the new Forum ! Not all is bad !)

jmac · Answer

I know this is a thread necro, but I have the same question, just somewhat different circumstances.

We have a project that is using the Cyclone V and our new product will be using the Cyclone 10 GX. We have a QSYS design created for all of our fabric to ease our way into re-configurable modules. Our code is stored in a GIT repository and all of our code is written in either pure Verilog or System Verilog

Would the best way to move forward just to be branching the two projects and patch between them with some manual configuration of the QSYS files? Is there an easier method? We currently have 4 versions that we build for the different hardware systems that we maintain. Would a 5th version work?

Thank you for your advice

jmac · Answer

Hi everyone,

The solution I have found for interoperating between the two build systems and FPGAs is:
* Create a separate source directory for the .qsf, .qpf, and .qsys files.
* Copy in the .qsf &amp; .qsys files, Create a new .qpf
* Set the build (.qsf) file to build in this new directory
* Reference your already existing verilog file directories
* Hope that any ip that you have previously used is compatible between the two architectures

Using the above method, It has allowed the old build to continue and it appears the new FPGA is functioning correctly too!

Forum Discussion

How to best share code between projects in Quartus Prime Standard and Quartus Prime Pro ?

5 Replies

Recent Discussions

Quartus did not start

Self service license server doesn't work

Timing analysis - long combinational path

Docker image for Quartus Pro 26.1 missing ?

Error (292014): Can't find valid feature line for core SLL_CA_HBC_T001_Hyperbus_Memory_Controller_10