Forum Discussion

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

HAL component not built in system library...

I am building software for designs that include a user logic module for which I have a custom API. I use HAL to package up this API so that it&#39;s built with the system library in the N2IDE. The API does not fit into HAL&#39;s generic device model, so all I do is create the HAL directory structure in <Quartus project dir>/<user logic module name>/ and populate it with <module name>.h, the API header and source files, and component.mk (as described in the Nios II SW Developer&#39;s Handbook). I can create and build a new application project and system library without a hitch; N2IDE finds the HAL component and builds the API source files, and the application has no problem finding header files and linking with object code from the custom API.

Then I&#39;ll go off and create new software projects for different designs, close the IDE, and come back to the original application I was working on. I fire up Quartus, download the design, and go to N2IDE to run my app. N2IDE tries to build my app, but this fails because none of the header files for my custom HAL API are found. I rebuild the system library, but from the C-Build messages, I can tell that it doesn&#39;t pick up the API&#39;s source code any longer.

I compared the <system library dir>/Debug/system_description/generated_all.mk files from two projects: one that I just created and built successfully, and one that I "revisited" and no longer recognizes my API. In the shiny new project, generated_all.mk includes this macro definition:

COMPONENTS_DEVICE_DRIVERS = /cygdrive/c/altera/kits/nios2/components/altera_avalon_dma

/cygdrive/c/altera/kits/nios2/components/altera_avalon_spi

/cygdrive/c/Work/NewProject/Quartus/user_logic_module

There it is: my user logic module directory, under which I&#39;ve organized the API source files in a HAL-friendly manner.

In the revisited and now broken project, the directory where my API lives is no longer referenced in generated_all.mk:

COMPONENTS_DEVICE_DRIVERS = /cygdrive/c/altera/kits/nios2/components/altera_avalon_dma

/cygdrive/c/altera/kits/nios2/components/altera_avalon_spi

What&#39;s going on here? Is there any reason why rebuilding the system library should cause it to lose all knowledge of my API?

I can work around this issue in two ways:

- recreating the application project

- re-generating the SOPC Builder system

... but naturally I&#39;d rather not have to do either. Any ideas? Is this issue fixed in Service Pack 1?

2 Replies

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

    I believe the issue has to do with project-local components versus installed components. SOPC Builder will discover components placed inside the Quartus/SOPC Builder project directory and update its install registry with that information. But if SOPC Builder enumerates components for another project at another point in time, the install registry will lose the original project-local component.

    The solution is to put the component in its own directory, outside of an SOPC Builder project, and tell SOPC Builder where it lives. You can also just tell SOPC Builder where the project-local component is and reference this from another project, but the possibility of a mix-up seems greater.

    To tell SOPC Builder where additional components may be found, use either the File->SOPC Builder Setup... configuration dialog or add the path to your environment variable SOPC_BUILDER_PATH. Both specifiers are plus ("+") delimited directory listings which point to the directory containing the component directory (i.e. two levels above the class.ptf file). This lets more than one component live in the directory pointed-to by the SOPC_BUILDER_PATH. Subdirectories deeper than this are not searched.

    The other piece of the puzzle here is that the code which produces generated_all.mk uses the SOPC Builder component registry to populate its COMPONENTS_DEVICE_DRIVERS list. By making your component permanently visible to SOPC Builder, you should have consistently good .mk files.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    21 years ago

    Thanks, that clears things up a lot. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

    I&#39;m working with many software projects, each of which has its own hardware design, and I&#39;d like to keep my directory structure as it is (one project directory contains the hardware and software portions of the project). I&#39;d have fewer hoops to jump through if SOPC Builder re-populated its component registry with local components every time. Just a suggestion!