Software Driver for Qsys Subsystem

[Altera_Forum]

Does anyone know a way to include software into a BSP for a QSys subsystem?  

 I frequently have SOPC systems which contain multiple components which serve a single function (for example, a chain of streaming adapters). I would end up having to connect the same components, the same way, in multiple projects, and it got repetitive and really clutters the SOPC system. I was very happy to see that Qsys now supports hierarchical systems, so I can create a subsystem once and re-use it.   Now my problem is, I would like to create a software driver for that sub-system, but I can find no good way to do it. I even went so far as to create a blank component with no interfaces and no HDL files so that I could associate the software driver with that, but then I realized that the component had to be a slave to the Nios to have a driver. I suppose I could add a dummy slave and connect it to the Nios to make that plan work, but that just seems a bit silly.

[Altera_Forum]

Or just define the hardware register layout in a .h file of your own - exactly the same way as you would if writing a driver for a physical device. 

 The only thing you really need from the SOPC system is the base address - and if your projects are reasonably similar you can probably use a common(ish) base address. The 'automatic' base address assigments I've seen failed to partition the devices into sane groupings - much easier for debug (etc).

[Altera_Forum]

Thanks for the reply!  

 Where would I put that .h file? In the case of a component driver, I would store it with the driver (in subversion), and create a _sw.tcl script so that it gets incorporated into the BSP. If I have a library component (or in this case, a qsys subsystem) in version control somewhere, I would like to store the software files with it, so that I can just check it out once. I could store the driver with my software code, or in a separate SVN path which I can check out as an external along with my software code; and I may have to accept that. But I think it would be preferable if it could be stored along with the qsys subsystem, and automatically included in the code by the SBT when that component is instantiated in the system.  In fact, generally I'm thinking of a driver with a lot more functionality than just macros for register access, but I think the issue applies both ways.