Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12409 Discussions

Software Driver for Qsys Subsystem

Altera_Forum
Honored Contributor II
989 Views

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.
0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
89 Views

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
Honored Contributor II
89 Views

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