QSYS flattens our design hierarchy

[Altera_Forum]

Hi all, 

 We are migrating from Xilinx to Altera and so far everything is running ok. As an alternative to Xilinx IP-integrator, we've now moved to QSYS. Here we get problems.  First issue: It seems QSYS copies all files from our IP to one single directory! (/synthesis/submodules) Doing this, it overwrites files with the same name, which is a big problem. We have a large IP database, build up over many years. Each IP block contains a version of common packages (i.e. common_pkg.vhd). But due to new insights or upgrades, the contents of these files can differ between IP blocks. -We do not want versioning in the file name (e.g. common_pkg_v1_0.vhd), we want a specific version within a specific IP block directory-  Second issue: even if the file name would be different, it seems QSYS compiles everything into one VHDL library! This gives the same problem again: packages or components with the same name are overwritten. It might also all our library references in the code to malfunction, but we weren't able to check that yet.  So two questions: - How do I specify the directory QSYS should copy the files in? (e.g. /synthesis/submodules/[IPmodule]/) - How do I specify the library the IP block files should be compiled in? (i.e. not the default)  In Xilinx IPI this is quite easy. But after an extensive search I've found no way to do it in QSYS. I am quite worried about the information I found here: http://www.alterawiki.com/wiki/new_qsys_issues If these things are not possible, I would be stumped. It would make QSYS unusable for us :/

[Altera_Forum]

I think it is possible to have Qsys generate into folders. I say this because if you instantiate code generated from Altera's DSP builder, it will be allocated into folders in the /synthesis/sudmodules/ path. 

 However, if you are using component editor (the GUI), there might not be a way to set this property. You will have to manually edit the "component"_hw.tcl file that qsys uses to set this information in.  When looking through this tcl file I see a command:  add_fileset_file "vhd design file path" VHDL PATH "another vhd path"  Normally I see add_fileset_file command on their own so these get flattened in the submodule folder. I think the VHDL PATH command is the key because it specifies the path within the submodule folder where the vhdl file will be placed. But you will have to edit the _hw.tcl file by hand.  Hope that made sense...

[Altera_Forum]

Thanks! 

So I managed to get the files in a seperate directory using add_fileset_file .//.vhd VHDL PATH /.vhd That solves issue# 1  Issue# 2 is still there: all files are compiled into one library.  I have tried the following: 

• change the value set %libraryName% "TstoUdp". Which is probably a stupid idea :oops:  
• do a TCL replace action using "get_qip_strings" and "set_qip_strings". But is seems get_qip_strings does not work and that set_qip_strings can only be used to add extra strings, not to replace or change existing ones.  

  So both do not seem to work.  Of course I could manually change the QSYS generated .qip-file, but that's not the point. I would like to be able to set the library in QSYS or the _hw.tcl.

[Altera_Forum]

I don't fully understand your library concern. Say you start a qsys file: IP.qsys, then when you generate all your files will be generated into IP/synthesis/submodules and the .qip file will specify set_global_assignment -library "IP" 

 Are you trying to generate several IPs at once and want to distribute them into different folders? Why can't you generate 1 IP at a time, and each time start a different qsys file?

[Altera_Forum]

Lets say I am generating a QSYS project "unsaved" with two IP blocks: TsToUdp and UdpToFrame. 

The TsToUdp_hw.tcl has the line: add_fileset_file ./TsToUdp/Common_pkg.vhd VHDL PATH Common_pkg.vhd  The UdpToFrame_hw.tcl has the line: add_fileset_file ./UdpToFrame/Common_pkg.vhd VHDL PATH Common_pkg.vhd  these are different versions of the same package, so they have different contents!  But QSYS generates the file unsaved.qip with the following lines: set_global_assignment -library "unsaved" -name VHDL_FILE set_global_assignment -library "unsaved" -name VHDL_FILE   Thus both files are compiled into the same library, one overwriting the other! This will cause one of our IPs to fail during synthesis. I would like QSYS to generate the following: set_global_assignment -library "UdpToFrame" -name VHDL_FILE set_global_assignment -library "TsToUdp" -name VHDL_FILE

[Altera_Forum]

I'm not sure that is possible..... 

 Considering Common_pkg in TsToUdp is NOT the same as Common_pkg in UdpToFrame, it might be better just to give them different names.  Did you try generating with the folder fix? Does this still cause overwrites? I'm thinking that maybe if these files are the same name but in separate folders, then you shouldn't have an issue even if they are referenced to the same "library".

[Altera_Forum]

I've noticed similar annoying "features" with Qsys and VHDL. Using a .qip file to describe your IP can solve both of your problems. The .qip file can be dynamically generated from Tcl if you have machine-specific installation differences. 

 Here's how the .qip solved my particular problems:  1. Qsys copies HDL files  If you use a .qip file, Qsys copies (or generates) a .qip file in the qsys_system/synthesis directory, and that file can reference the source code (in source version controlled folders).  2. VHDL libraries  You can specify the VHDL library to compile source into in a .qip file.  I *think* these are shown in the example file I posted in this thread ...  http://www.alteraforum.com/forum/showthread.php?t=48802  If not, ask and I'll try to post something a little more complete.  At least you know what you want to do is possible now :)  Cheers, Dave

[Altera_Forum]

@krasner: we have build up an extensive library over the years. Renaming files will take a lot of time and effort. Furthermore, company policy says that if we change sources, we will have to re-verify, re-validate and re-test all this legacy code: more effort. 

VHDL libraries have been there like forever and use of them is perfectly valid VHDL: why doesn't Altera support this properly?? We want to migrate from Xilinx (Vivado) IP-integrator -that has no issues with libraries at all-. I am having a hard time selling this to my superiors...  @Dave: I have tried that. The problem is that Qsys only copies the .qip file, not the VHDL sources. As a result the .qip file does not work, because it contains relative paths like below: set_global_assignment -name VHDL_FILE -hdl_version VHDL_2008 -library UdpToFrame   A big difference I've noticed when migrating from Xilinx to Altera is that in Wuartus II you can configure and tweak EVERYthing... So why is Qsys offering so little settings???

[Altera_Forum]

why do my posts in this tread suddenly require moderator approval? 

 Is it when I use the word "Xilinx" in a post? <- no this works. Strange.  What I tried to say:  We are trying to migrate from Xilinx to Altera. Xilinx IP-integrator has no issues with libraries whatsoever. Seems logical, as libraries in VHDL have been there like forever. It is perfectly valid VHDL to use them. We build an extensive IP database on top of that. Changing filenames (and entity/package names) will be a lot of work. Furtermore, company policy would require us to re-verify, re-validate and re-test all the code and our devices if we change the sources. It is kind of hard for me to sell this to my superiors.  When migrating from ISE to Quartus II I notices that Quartus II has settings to change and tweak Everything! So I don't understand why Qsys seems to be the opposite, offering little settings to change. *not even the VHDL library per block!*  @Dave: I tried that, but I get the problem that only the .qip file is copied, and not the vhdl sources. As a result the qip file does not work, as it contains relative paths. Example: set_global_assignment -name VHDL_FILE -hdl_version VHDL_2008 -library UdpToFrame

[Altera_Forum]

@dave: I continued your suggestion, by putting hard paths in my .qip-file. E.g. 

set_global_assignment -name VHDL_FILE -hdl_version VHDL_2008 -library UdpToFrame /SCM/FPGA/BuildingBlocksV2/IP/UdpToFrame/Source/Common_pkg.vhd  this seems to work, but GREATLY reduces flexibility of where we can check-out the files. A relative-path solution would be preferred....  In the code in your link you seem to refer to an environment variable ($::env(VHDL)). Would work, but isn't there a nicer way?  @anybody else then dave: your help is also appreciated ;)  Should I kick-off a change-request at Altera?

[Altera_Forum]

--- Quote Start ---   this seems to work, but GREATLY reduces flexibility of where we can check-out the files. A relative-path solution would be preferred....  In the code in your link you seem to refer to an environment variable ($::env(VHDL)). Would work, but isn't there a nicer way?   --- Quote End ---   In my latest versions of the .qip code, I use Tcl to copy a template file and modify that file to set a VHDL variable.  I had to stop using $::env() variables as the support is broken in 15.0 in some of the Qsys Tcl interpreters (the env still exists, but user variables like VHDL are missing). My comments from the attached _hw.tcl file are:   # QIP file generation # ------------------- # # Quartus copies the .qip file to the build area, so the .qip # file cannot reference source files using relative paths. # Quartus 13.1 and on execute the _hw.tcl files in a Java # Tcl interpreted that has several restrictions; # # * The environment ::env does not include any user-defined # values, so you cannot set a VHDL_PATH variable on the # NIOS II IDE shell command-line and reference that # variable in the _hw.tcl script. # # * The variable ::quartus is not available in all versions # # * The Tcl support provided by the Java VM is incomplete # # - set path does not work, so use # set path is a work-around # # - set path does not work, so use # set path ] # # The file path in the _hw.tcl file is relative to the _hw.tcl # script, so accesses to the template files do not need a full # path.    I've uploaded a zip that contains the _hw.tcl file, a top-level wrapper template, and a .qip template.   The top-level template was required so that I could reference the VHDL library and package, and to use a 'real' data type (the Qsys GUI accepts a string entry, and the Tcl converts it to a VHDL 'real' type).  The Tcl modifies the variable VHDL_VAL to reflect the source location. The .qip file compiles the source into a 'control' library - the same library referenced by the top-level wrapper VHDL.  This "solution" was determined by trial-and-error. If anyone has a better solution, please let us know!  Cheers, Dave

[Altera_Forum]

Thank you Dave, I will try your suggestion. 

Project management has accepted the hard paths in the qip-file for now, so we have something we can work with. However, I do not consider this case closed until Altera Qsys allows library assignment per IP block.  This is so weird to me. VHDL libraries have been defined in the IEEE 1076-1987 VHDL standard already (section 11.2). Why is Altera still supporting them so badly after 28(!!) years?

[Altera_Forum]

--- Quote Start ---   Project management has accepted the hard paths in the qip-file for now, so we have something we can work with.   --- Quote End ---   Arguably they are not hard paths, since they are dynamically generated by the Tcl script :)    --- Quote Start ---   However, I do not consider this case closed until Altera Qsys allows library assignment per IP block.  This is so weird to me. VHDL libraries have been defined in the IEEE 1076-1987 VHDL standard already (section 11.2). Why is Altera still supporting them so badly after 28(!!) years?  --- Quote End ---   I agree. Their VHDL support is terrible in multiple places, check out the comments at the end of the Avalon-MM BFM tutorial I wrote:  https://www.ovro.caltech.edu/~dwh/correlator/cobra_docs.html https://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_avalon_bfm_master.pdf https://www.ovro.caltech.edu/~dwh/correlator/pdf/altera_avalon_bfm_master.zip  Cheers, Dave