Forum Discussion

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

implementing a QSYS snap-in, and the default QSYS search path

Hi,

I think its a good idea to implement QSYS snap-ins so, for example, the same generic processor design could be used with different external memory interfaces. I have been doing this with the component editor and just routing the interface out to a conduit. However, another way would be to adopt a common interface for a QSYS component and just find different implementations of this interface in the QSYS search path. However, the QSYS default search path isnt clearly described in the doc. Experimental evidence seems to indicate that the default search path is maybe relative to the file that is currently being edited. For example, if I have a user_component.ipx in the current working directory (see below) when I run qsys-edit not specifying a file to edit, and the qsys-edit command line help indicates that the project directory defaults to the cwd, then I do see my snap-in component in the project area on the LHS of the QSYS GUI. However, when I subsequently open a QSYS file from an unrelated location then my snap-in component vanishes (and it isnt found by QSYS). Does anyone know the explicit details about the QSYS default search path?

<library>

<path path="../ip/**/*"/>

<path path="../ip/*"/>

</library>

Thanks,

7 Replies

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

    There's an undocumented (or poorly documented) environment variable that you can set; IP_IPX_PATH

    This variable can contain a comma separated list of paths to .ipx files, and the .ipx files can be created with ip-make-ipx.exe

    Look at the source code associated with this tutorial

    http://www.ovro.caltech.edu/~dwh/correlator/pdf/esc-104paper_hawkins.pdf

    The script

    ESC-104Code_Hawkins\dsp_tutorial\vhdl\boards\de0_nano\cyclone4\dsp_tutorial\scripts\synth.tcl

    shows how to create this path dynamically using Tcl.

    There's bound to be other alternatives, but this might give you an idea ...

    Cheers,

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

    Thanks Dave. I tried starting QSYS version 13.0 sp1 after setting the IP_IPX_PATH=".,$", but observed the same problem where QSYS forgets its search path configuration as soon as a file is opened. I did also try placing absolute paths in the xxx.ipx file with no change in behavior.

    Thanks also for the attached document.

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

    Service request 10997669 -- QSYS 13.1 sp1 forgets search path passed in on the command line

    1) Add a xxx.ipx file at the current working directory as follows.

    <library>

    <path path="../ip/*"/>

    </library>

    2) Add a user generated component into the "../ip" path.

    3) Run the following command when the current working directory is at the location where you have created the xxx.ipx file.

    qsys-edit --search_path=".,$"

    4) You will see the user's custom component in the project area on the LHS of the QSYS UI.

    5) Next open any QSYS file at another unrelated location and then the custom component disapears from the project area on the LHS of the QSYS UI.

    6) Furthermore, observe that the projext area on the LHS of the QSYS UI contains now some QSYS files that are in a <unrelated location>/ip/**/* type of path. However these files were never added to the search path?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    When attempting to use the options dialog in the GUI as a manual override for the broken project specific ip path configuratiuon, the search path appears to remain to be somehow modal, based on the path to the QSYS file that is currently open, and not based on a 2nd path entry in the user's path configuration in the options GUI (which is presumably user-specific and not qsys-file-specific or project-specific configuration but the documentaion isnt revealing that type of details).

    So at the moment I havent made any progress on a viable workaround.

    I updated the QSYS wiki page indicating that the problem is remaining in 13.0 sp1, and perhaps wasnt fixed in 12.0 as indicated.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Another observation is that using the options dialog in the GUI as a manual override for the broken project specific ip path configuratiuon works, but only if I place the ip directly in the path configured, and dont rely on the recursive subdirectory search. For example <path>/* works, but <path>/**/* doesnt.

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

    Another observation is that using a generic QSYS system with a sub-system snap-in would be more useful if we could designate QSYS exports to be conduits. For example, we have a subsystem xxxx.qsys which is used in project y and project z. In project y xxxx.qsys has different exports than in procet z. Therefore, presumably in the top level QSYS system that instantiates xxxx.qsys we will always see port connection errors unless we can designate certain exports to be conduits.

    Yes, we could implement the subsystem with conduits in VHDL and use the component editor, or a manually generated QSYS script, but then we loose the ability to autoconfigure any QSYS peripherals instantiated into such subsystems into the HAL BSP using nios2-bsp. This is one of the reasons to use QSYS, of course.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    12 years ago

    Thanks for posting this depressing state of affairs ...

    Why do Altera try to implement a "custom" solution (GUI check boxes, database entries, broken Tcl versions/environments, etc), when standard solutions would not cause so many headaches ... :(

    Cheers,

    Dave