Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
2,438 Views

Custom ip: can't see IRQ number in system.h

Hello, 

 

I'm trying to create a custom component which should generate an interrupt to the NIOS. 

My problem is that the BSP generate the system.h with no interruption for the component. 

Qsys plugged it to input 4, but BSP irq value is -1 as well as irq_interrrupt_controller_id 

I tried to follow several document from Altera literature but no success. 

 

The component has an Avalon MMSlave, a clock input, a reset input, an Interrupt Sender and several Conduit. 

in the _sw.tcl there is the isr_preemption_supported set to true and supported_interrupt_apis to "legacy_interrupt_api enhanced_interrupt_api". 

The driver code contains only the _regs.h file 

 

The vhdl skeleton of the device is created but not the full behaviour, I don't think that BSP generation check this level of detail. 

 

Can anyone help me with this issue? 

Thanks
0 Kudos
19 Replies
Altera_Forum
Honored Contributor I
254 Views

Which version of the tools are you using? I remember running into this in the early days of Qsys but I thought these issues were fixed. -1 represents a disconnected interrupt number so assuming you have connected the interrupt sender to the receiver (Nios II) I would have expecting the interrupt number to be populated in system.h instead of -1. Often when I ran into this issue it was when I fed the interrupt through a bridge connection (often to drive it up or down the Qsys system heirarchy). So if you describe the connectivity more I might have a workaround that will work for your system.

Altera_Forum
Honored Contributor I
254 Views

I use Quartus 13.1 and no bridge in the design. The sender is connected to the NIOSII receiver with automatically assigned numbers. This one is the 4 in Qsys. I checked others IRQ numbers from standard peripherals 0,1,2,3 and 5 are correctly populated in system.h 

In one of the Altera's paper they recommend to get inspired with existing components such as jtag_uart which i did. 

I checked the qsys file and my irq is connected just like the 5 other
Altera_Forum
Honored Contributor I
254 Views

That's odd indeed. Did you use the component editor to create the custom core or did you write the hardware .tcl file from scratch? You might need to attach the tcl file to this post so that we can take a look.

Altera_Forum
Honored Contributor I
254 Views

At first I used the component editor, then when it didn't generate what I was looking for, I started to change to mimic the irq part of the jtag_uart component 

The tcl file is attached. Let me know if you find something in it.
Altera_Forum
Honored Contributor I
254 Views

The BSP generation show a warning: WARNING slave name not found system parameter 'associatedAddressablePoint' for the Interupt sender irq0 

I just found the error: the parameter "associatedAddressablePoint" has to have the name of the Avalon interface, s0 in my case.
Altera_Forum
Honored Contributor I
254 Views

 

--- Quote Start ---  

The BSP generation show a warning: WARNING slave name not found system parameter 'associatedAddressablePoint' for the Interupt sender irq0 

I just found the error: the parameter "associatedAddressablePoint" has to have the name of the Avalon interface, s0 in my case. 

--- Quote End ---  

 

 

I have exactly the same problem using Qartus-II 13.1 (haven't tried with other versions though). As mentioned above, the solution is to set the value of 'associedAddressablePoint' in the sopcinfo file to the name of an avalon interface on the component.  

 

This looks like a bug to me, or is there another way to solve this than editing the sopcinfo file?? 

 

Thanks to vinc29 for pointing out the current solution!
Altera_Forum
Honored Contributor I
254 Views

I don't know of a workaround but my suggestion is to submit a service request and attach the system and custom component to the SR so that the Qsys engineering team can take a look. This is the link to file a service request: http://www.altera.com/mysupport 

 

If this issue started in a certain version you might be able to workaround it by requesting a different .tcl API by editing the .tcl file. Doing so may cause other things to break since the component was created with a newer component editor which used a newer .tcl API so make sure you backup the .tcl file first.
Altera_Forum
Honored Contributor I
254 Views

Was this issue ever fixed? I have the same problem, but cannot figure out how to implement a solution. I created a simple I2C slave device in HDL and plugged it into the nioss via qsys. Everything looks normal like the above situations, but when I do Nios II -> generate BSP in eclipse I get the -1 value in my system.h for IRQ and IRQ_INTERRUPT_CONTROLLER_ID. 

 

I'm using Qsys 13.1 Build 162 and Quartus 13.1.0 Build 162 web edition. 

 

Also, to fix this, where do I find associedAddressablePoint setting? 

 

Solved: 

-------- 

 

So the problem I had wasn't this bug, but sounded just like it. I had two custom avalon MM slave peripherals and each had a MM slave interface. If you go into the interfaces tab of the custom peripheral in Qsys (the ones that you made) you will see an interface for avalon_mm_slave or something like that. Here is a screenshot of one of mine. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=9071  

 

It turned out that both of these peripherals had the exact same name for this interface. This one (from screenshot) was the second one I built and when I generated my bsp/sopc file the component_name_hw.tcl file for this second peripheral did not get built correctly because of this leading to my system.h file in eclipse not having the correct interrupt and interrupt controller information. Instead of 5 and 0 (which was the interrupt number and int. controller number I was supposed to have) it just had -1, -1 respectively. after changing the interface name to something else on this second peripheral the *_hw.tcl file was built correctly and section of the system.h file in my eclipse C-side is now correct. I haven't tested the interrupt with an ISR yet, but at least it is building the system.h file correctly.  

 

Long story short, heads up on naming convention for this interface regarding custom peripherals. Don't name them the same thing. This is easy to do because Qsys defaults here to avalon_slave_0 as the default name for the interface.  

 

Another note. The component_name_hw.tcl file is in the main quartus directory. 

 

Hopefully this helps someone out.
Altera_Forum
Honored Contributor I
254 Views

I met the same problem.  

And I try the way @m3atwad said: 'changing the interface name to something else on this second peripheral'. but it did not work. 

The attachment is my component's _hw.tcl~ , and here is part of system.h code generated by using the related sopcinfo  

 

 

# define alt_module_class_ezusb2nios_0 ezusb2nios 

# define ezusb2nios_0_base 0x0 

# define ezusb2nios_0_irq -1 

# define ezusb2nios_0_irq_interrupt_controller_id -1 

# define ezusb2nios_0_name "/dev/ezusb2nios_0" 

# define ezusb2nios_0_span 1024 

# define ezusb2nios_0_type "ezusb2nios" 

 

 

You can see, the IRQ and IRQ_INTERRUPT_CONTROLLER_ID is still -1. 

 

I don't know why
Altera_Forum
Honored Contributor I
254 Views

Hey billy, 

 

1. Do you have two custom components? 

2. Did you make sure (by using qsys and looking at the interfaces tab) you didn't violate the same thing I did? I think you wanna check the "Name" under your s0 module.
Altera_Forum
Honored Contributor I
254 Views

Also, 

 

As the guys above stated make sure your _hw.tcl file is correct. It is located in your root quartus project directory labeled projectname_hw.tcl. I've attached mine to this post so you can check it out. If you are getting the same warning mentioned above you may want to modify the "associatedaddressablepoint" with the name of you IRQ_RECIEVER in your Qsys custom component. I think you have to be careful to to make sure it is the name of the irq block in your interfaces tab and NOT the name of you Avalon Memory Mapped Slave which is probably s0. You can see in my that my irq sender is irq_s0.  

 

Side note: For some reason Qsys doesn't pick up changes made to custom components very well. You may have to add/remove the component a couple times before Qsys picks up the change. This is very aggravating especially if you don't realize your changes are not getting updated when you re-add the component you made changes to. 

 

 

Hope this info helps.
Altera_Forum
Honored Contributor I
254 Views

I only skimmed through the post so maybe I missed this but did you make sure the interrupt sender from your slave port is connected to the Nios II interrupt receiver? If not that will cause it to show up as a -1 in system.h

Altera_Forum
Honored Contributor I
254 Views

I am sure it is connected. And I checked qsys.v for that.

Altera_Forum
Honored Contributor I
254 Views

I have run into the same problem with my project in Quartus 13.1. I have two instances of a custom component in my design, and the interrupts are set to -1 in the system.h file. When I first checked the _hw.tcl file, the associatedAddressablePoint was blank. I had used the default "interrupt_sender" name in the component, so I renamed it. After I regenerated the component with this change, the associatedAddressablePoint was set as follows: 

# # connection point AD9637_irq_sender#  

add_interface AD9637_irq_sender interrupt end 

set_interface_property AD9637_irq_sender associatedAddressablePoint AD9637_irq_sender 

set_interface_property AD9637_irq_sender associatedClock adc_clk 

set_interface_property AD9637_irq_sender associatedReset reset 

set_interface_property AD9637_irq_sender ENABLED true 

set_interface_property AD9637_irq_sender EXPORT_OF "" 

set_interface_property AD9637_irq_sender PORT_NAME_MAP "" 

set_interface_property AD9637_irq_sender CMSIS_SVD_VARIABLES "" 

set_interface_property AD9637_irq_sender SVD_ADDRESS_GROUP "" 

 

add_interface_port AD9637_irq_sender ad9637_irq irq Output 1 

 

I then fully replaced the components in qsys and verified that the interrupt sender name changed on the component. I assigned the IRQ in qsys and re-generated the design and the BSP for the Nios. However, I still do not see the interrupt in system.h: 

 

/* 

* AD9637_interface_0 configuration 

*/ 

# define AD9637_INTERFACE_0_BASE 0x1000# define AD9637_INTERFACE_0_IRQ -1# define AD9637_INTERFACE_0_IRQ_INTERRUPT_CONTROLLER_ID -1# define AD9637_INTERFACE_0_NAME "/dev/AD9637_interface_0"# define AD9637_INTERFACE_0_SPAN 1024# define AD9637_INTERFACE_0_TYPE "AD9637_interface"# define ALT_MODULE_CLASS_AD9637_interface_0 AD9637_interface 

 

 

/* 

* AD9637_interface_1 configuration 

*/ 

# define AD9637_INTERFACE_1_BASE 0x1400# define AD9637_INTERFACE_1_IRQ -1# define AD9637_INTERFACE_1_IRQ_INTERRUPT_CONTROLLER_ID -1# define AD9637_INTERFACE_1_NAME "/dev/AD9637_interface_1"# define AD9637_INTERFACE_1_SPAN 1024# define AD9637_INTERFACE_1_TYPE "AD9637_interface"# define ALT_MODULE_CLASS_AD9637_interface_1 AD9637_interface 

 

Anyone have suggestions?
Altera_Forum
Honored Contributor I
254 Views

I wish I had some more information. This problem came back for me with a single custom component. I can't seem to solve this. As a work around, you can manually place the IRQ number and IRQ controller number in the system.h file. I wish this worked because it is a headache when you are developing and regenerating your bsp.

Altera_Forum
Honored Contributor I
254 Views

When either of you run into this issue is there any components between the master and slave like bridges by any chance? Likewise is the master and slave at different levels of the heirarchy? The reason why I'm asking about masters and slaves is because interrupts are tied to MM interfaces so this information might help find the culprit.

Altera_Forum
Honored Contributor I
254 Views

Hey Omen, 

 

I am not using any bridges in any of my designs. I have a few simple ones that I've checked this issue out and I've seen it across all of them. As for the hierarchy I'm not sure exactly what you mean. I have a nios cpu with a custom peripheral attached to it in qsys. For example, I wrote an I2C ip core. The core works fine, but when I generate a new bsp it resets the interrupt defines discussed above to -1. I just connect the peripheral to clock, master data line and some output conduits. I attached some pics so you can see...maybe I do have a hierarchy concern and just don't realize it. 

 

Qsys screen: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9514&stc=1  

 

System.h file: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9515&stc=1  

 

Quartus entities: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9516&stc=1  

 

One thing I actually just noticed is that my interrupt line (shown in the pic where the# 2 is) is line up with my clk signal and for all of Altera's stuff it is lined up with the MM port.
Altera_Forum
Honored Contributor I
254 Views

Ya that interrupt being aligned to the clock is the first thing I noticed when I looked at it. I recommend taking a look at a simple component like the avalon PIO hardware .tcl file to see how it relates the interrupt to the slave port. I think you might be relating it to the clock input or nothing at all in your hardware .tcl file and that might be the culprit. The reason why it needs to be related to the slave port is so that software knows which slave port it's going to be accessing to clear the interrupt (imagine having multiple copies or a component with multiple slave ports and that's why this is necessary). So I think due to a lack of that associating when the system.h is generated when it comes across the slave port it doesn't think that there is an interrupt paired up with it.

Altera_Forum
Honored Contributor I
254 Views

Hey guys, 

 

So I've got some updates as I've finally gotten my IP component working and the Eclipse SBTs have been building my system.h file with IRQ and IRQ_CONTROLLER numbers that match my Qsys design. If you look at my above post you can see my IRQ line is even with my clock input for my I2C component which is wrong (pointed out by BadOmen). I think this was due (as mentioned by two guys on the first page of this thread) to my  

 

set_interface_property s1_irq associatedAddressablePoint ""  

 

being blank. I added my addressable point: 

 

set_interface_property s1_irq associatedAddressablePoint "s1_irq"  

 

which I got from the last line here, line add_interface_port etc... 

 

add_interface s1_irq interrupt end set_interface_property s1_irq associatedAddressablePoint "s1" set_interface_property s1_irq associatedClock clock set_interface_property s1_irq associatedReset reset set_interface_property s1_irq ENABLED true set_interface_property s1_irq EXPORT_OF "" set_interface_property s1_irq PORT_NAME_MAP "" set_interface_property s1_irq CMSIS_SVD_VARIABLES "" set_interface_property s1_irq SVD_ADDRESS_GROUP "" add_interface_port s1_irq avs_s0_irq irq Output 1  

 

Once I changed this you can see my IRQ line is now moved down to my Avalon MM interface. IRQ3 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9531&stc=1  

 

 

After I synthesized this and rebuilt the HAL bsp my interrupt numbers came up: 

 

/* * I2C_Master_RXTX configuration * */ # define ALT_MODULE_CLASS_I2C_Master_RXTX I2C_Master_RXTX# define I2C_MASTER_RXTX_BASE 0x0# define I2C_MASTER_RXTX_IRQ 3# define I2C_MASTER_RXTX_IRQ_INTERRUPT_CONTROLLER_ID 0# define I2C_MASTER_RXTX_NAME "/dev/I2C_Master_RXTX"# define I2C_MASTER_RXTX_SPAN 16# define I2C_MASTER_RXTX_TYPE "I2C_Master_RXTX"  

 

I think this problem shows up in Qsys when you create your IP component. Check the Associated addressable interface out under your IRQ sender interface when building the component. I think you want this: 

http://www.alteraforum.com/forum/attachment.php?attachmentid=9532&stc=1  

 

The problem I had is that the drop down never had my interface. It only had none. So I guess setting the addressable point in the .tcl file as recommended by the guys earlier in this posts fixes this.  

 

Hope this is helpful! 

Rob
Reply