Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
10 years ago

QSYS flattens our design hierarchy

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 :/

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    @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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    @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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    10 years ago

    --- 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