SOPC - Interface To User Logic

[Altera_Forum]

Hi, 

 I have ported an old Nios project to Nios II. Unfortunatly, the designers of the old project didn't used custom components to incorporate user logic but they used the "Interface To User Logic - Avalon Memory Mapped Slave".   I'm using Quartus II (and SOPC) version 9.0. There is no such component "Interface To User Logic". I think that's because it is deprecated.  But I would like to get some informations about it in order to understand the Nios c-Code that is communicationg with the interface.  One problem for me is that I don't know what is the definition of MY_INTERFACE_SPAN in the system.h file. I can't find something corresponding in the excalibur.h file of the NIOS I. I also don't know, how to access the adress, writedata and readdata of the the interface because I only have a MY_INTERFACE_BASE Adress. . .   Finally, my question is, if somebody knows where I can find documentation about the "Interface To User Logic" and if somebody has experience in porting this component from Nios to Nios II.  Thanks, Maik

[Altera_Forum]

Okay here we go... 

1 - There is no interface to user logic component anymore. The reason is that it's trivial to create your own. Basically all you do is use the "New Component Wizard" from within SoPC builder to create your new component. You just create the appropriate signals (either manually or using a template) and configure the interfaces appropriately (timing, latency, etc.). Then because the component is not based on HDL, when you create an instance of the component in your SoPC system, it's signals will automatically be exported to the top-level where you can connect them to your user logic. Recommended reading: http://www.altera.com/literature/lit-sop.jsp  However, if this seems daunting I've attached a generic component that is based on HDL that exports the avalon signals out of the system. You can use it if it meets your needs.  2 - The macro found in system.h "<COMPONENT_NAME>_SPAN" (in your case MY_INTERFACE_SPAN) is merely a macro that can be used to determine how much address space is occupied by the component on the avalon bus. It is rarely used. The other macro <COMPONENT_NAME>_BASE (in your case MY_INTERFACE_BASE) refers to the base address of the component on the NIOS processor's bus. This macro is very important as it tells you where to access your component on the bus. As far as accessing the component, you've been given it's address on the bus so you know where it is and in theory you can access it however you want. However, Altera provides the IOWR and IORD macros specifically for acessing your hardware components. Please see page 9-4 of this document: http://www.altera.com/literature/hb/nios2/n2sw_nii5v2.pdf  Jake

[Altera_Forum]

Hi Jake, 

 thanks for your answer!    --- Quote Start ---  2 - The macro found in system.h "<COMPONENT_NAME>_SPAN" (in your case MY_INTERFACE_SPAN) is merely a macro that can be used to determine how much address space is occupied by the component on the avalon bus. It is rarely used.  --- Quote End ---    This seems to be an important information for me. In the c-Code I heired through this project, old project, I found something like this:  alt_u32* p1 = (alt_u32*) MY_INTERFACE_BASE; alt_u32* p2 = ((alt_u32*) MY_INTERFACE_BASE) + 1;  I had no idea, where these pointers are pointing to, because the data bus of my external component is only 8 bits wide. But the MY_INTERFACE_SPAN macro is 8.   In the end, I still don't know, hoe SOPC (or whatever tool) knows, how to define this SPAN macro because as i said in my external component the writedata bus is 8 bits, the readdata bus is 8 bits, and it does exist an additional address bus of the width 4 bits.   Its very hard for me to understand what is going on here, but your explanations already helped a lot.  It is very hard for me to implement my interfaces to user logic components into the SOPC custom component because all these components are AHDL modules and I think I read somewhere, that SOPC only supports VHDL or verilog.  Maik

[Altera_Forum]

Although the external component is 8 bits, most likely it was interfaced to the avalon bus as a 32-bit component. Thus every register address to your component actually occupies 4 addresses on the Avalon bus. So, if your component has two register addresses (0 and 1), these would correspond to "MY_INTERFACE_BASE" and "MY_INTERFACE_BASE + 4". This is exactly what the pointer arithmetic does in the code you gave: 

alt_u32* p1 = (alt_u32*) MY_INTERFACE_BASE; alt_u32* p2 = ((alt_u32*) MY_INTERFACE_BASE) + 1;  Adding one to an "alt_u32*" actually adds 4. This results in two pointers pointing to the two registers of your component.  Jake

[Altera_Forum]

I would recommend to use the IO_RD/WR macros to access your component instead of pointers. With pointers you'll end up with problems with the data cache.

[Altera_Forum]

Hi Daixiwen, 

 thanks for your input, too.  Yes, you are right, the source code I heired is in many ways not like everything that i read about designing software for Nios II. But the first step will be to get it running like it has before. Fortunatly, the Nios II has neither Data nor Code cache (at least none which I am aware off . . . ).  I really welcome your answers even if they are as short as the one from Daixiwen. Even in short ones like this I can get some ideas about what to do and what better not to.  Thanks, Maik