Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16593 Discussions

QSYS output (synthesis) directory workaround?

Altera_Forum
Honored Contributor II
1,769 Views

Hello All, 

 

We recently started upgrading from SOPC builder to QSYS. There is one(...) big annoying difference between the two systems: When generating a system QSYS copies ALL files into a synthesis directory while SOPC builder adds qip files to your project. This results in two copies of the same file on your system. This is especially annoying when you use an ip-core library with version control. If you edit a file(bug-fix?) and forget to re-generate the QSYS system chances are that you only find out hours later out after full compile/fit. 

Is there a way to tell QSYS not to copy ip-core files to the synthesis directory and have the system reference the files directly from there initial location (like it was in SOPC?)? 

 

thanks, 

Jo
0 Kudos
8 Replies
Altera_Forum
Honored Contributor II
890 Views

Hi Jo, 

 

You can stop Quartus from copying files by using a .qip file. For example, here are the last lines of a Tcl generate procedure: 

 

 

--- Quote Start ---  

 

# Add the files to the project (Quartus copies the files) 

#  

# Generated instance 

add_fileset_file "$entity.vhd" VHDL PATH "$file" 

#  

# QIP File 

set vhdl $::env(VHDL) 

add_fileset_file avs_ltc1867.qip OTHER PATH $vhdl/lib/ltc1867/scripts/avs_ltc1867.qip 

 

--- Quote End ---  

 

 

I know this might not be enough information to understand what do to, so I'll upload a zip file with the component source. The component won't work for you, since its missing other dependent source (I just zipped a folder in my CVS tree), but at least you'll be able to see the _hw.tcl script and the associated support files. 

 

If you get stuck, ask questions. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

Hi Dave, 

 

Thanks for the answer. If I understand correctly you use an environment variable in your .qip files. This is not as easy-to-use as it was with SOPC builder but at least it is a lot easier than manually editing the qip file generated by QSYS. For the time being this will work just fine but I hope Altera will fix this in future versions. 

 

Thanks, 

Jo
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

Hi Joe, 

 

--- Quote Start ---  

If I understand correctly you use an environment variable in your .qip files. This is not as easy-to-use as it was with SOPC builder but at least it is a lot easier than manually editing the qip file generated by QSYS. For the time being this will work just fine but I hope Altera will fix this in future versions. 

 

--- Quote End ---  

 

 

The qsys Tcl package allows the use of ::env, whereas the sopc Tcl package did not. I use $::env(VHDL) to point to my source area, that way the scripts are portable between my various machines (the CVS checkout can be to a different folder). 

 

Both SOPC and Qsys have their "issues", eg., inability to handle VHDL reals, problems with booleans, etc. However, the wrapper solution shown in the attached zip avoids the issues with Qsys VHDL generics support. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

 

--- Quote Start ---  

 

 

The qsys Tcl package allows the use of ::env, whereas the sopc Tcl package did not. I use $::env(VHDL) to point to my source area, that way the scripts are portable between my various machines (the CVS checkout can be to a different folder). 

 

--- Quote End ---  

 

 

Because SOPC builder added the files directly to the project there was no need to use any environment variables. This allowed to have multiple versions of the same source on my system - or have multiple projects with each their own copy of the source.  

 

 

--- Quote Start ---  

 

Both SOPC and Qsys have their "issues", eg., inability to handle VHDL reals, problems with booleans, etc. However, the wrapper solution shown in the attached zip avoids the issues with Qsys VHDL generics support. 

 

--- Quote End ---  

 

 

I agree, lets hope the next tool will offer some improvements. 

Cheers, 

Jo.
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

 

--- Quote Start ---  

Because SOPC builder added the files directly to the project 

 

--- Quote End ---  

 

Hang on, read your original request above - you wanted to avoid copying the source to the Qsys directory :) 

 

Qsys will copy source if you use filesets that point to your HDL source. My workaround was to point the fileset to a .qip file (which gets copied), rather than the HDL. That way I can keep editing the HDL and rebuilding the system, without having to re-run Qsys (to get it to copy the modified source to its synthesis area). 

 

 

--- Quote Start ---  

 

there was no need to use any environment variables. This allowed to have multiple versions of the same source on my system - or have multiple projects with each their own copy of the source.  

 

--- Quote End ---  

 

 

If you don't like my use of environment variables, there are two other solutions;  

 

1. The ::quartus() array is available in most of these tools. If the environment is inherited when one tool starts the next, then you can put a variable in ::quartus and access it in the downstream tools. 

 

2. You can create a fake generic/parameter using set_parameter, and then access it later using get_parameter 

 

Personally I see no harm in setting a few environment variables :) 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

 

--- Quote Start ---  

Hang on, read your original request above - you wanted to avoid copying the source to the Qsys directory :) 

--- Quote End ---  

 

 

Let me rephrase: SOPC adds the file paths to the project qsf file without copying them :) 

 

 

--- Quote Start ---  

 

If you don't like my use of environment variables, there are two other solutions;  

 

1. The ::quartus() array is available in most of these tools. If the environment is inherited when one tool starts the next, then you can put a variable in ::quartus and access it in the downstream tools. 

 

2. You can create a fake generic/parameter using set_parameter, and then access it later using get_parameter 

 

Personally I see no harm in setting a few environment variables :) 

 

--- Quote End ---  

 

 

Thanks Dave, I will give this a try
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

 

--- Quote Start ---  

Let me rephrase: SOPC adds the file paths to the project qsf file without copying them :) 

 

--- Quote End ---  

 

Alas, that is no longer the case ... 

 

 

--- Quote Start ---  

 

I will give this a try 

--- Quote End ---  

 

No doubt it will take several iterations to get things working ... the Qsys tools are not exactly user-friendly when it comes to "fine control". Qsys does however make it easier to create the interconnect between components, so the effort is ultimately worth it. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
890 Views

Hello all, 

 

I think Altera has finally seen some light and they have changed the approach in Qsys pro (not tried yet).  

For those that still are looking for a work-around in qsys prime (vhdl):  

1: create a wrapper component that instantiates your ip toplevel. Make sure to have the component definition in your architecture, direct instantiation does not work. 

2: in qsys component editor, only add the wrapper file. should compile just fine 

3: add the newly created component to your qsys system and generate. 

4: manually create a qip file, listing all your component sources. 

5: manually add this file to your project. 

6: compile project. 

 

If your work like this the wrapper file wil be copied to the synthesis directory and the other file remain on their original location. The wrapper file only changes when the entity changes and then you'll have to re-generate qsys system any way. 

 

hope this helps. 

Jo
0 Kudos
Reply