Avalon Slave IP with Interrupt Receiver

[Altera_Forum]

We are trying to design an avalon slave that listens on the irq lines that are connected to the nios cpu. 

This slave should later on be able to count the individual irq's and freeze the nios when accessed via nios datamaster (by using waitrequest) until an irq occurs.  so we setup an sopc ip with the avalon slave signals as usualy done and added an interrupt receiver port with 32 bit. the tcl for this component has this section included  add_interface interrupt_receiver interrupt start set_interface_property interrupt_receiver associatedAddressablePoint avalon_slave_0 set_interface_property interrupt_receiver irqScheme INDIVIDUAL_REQUESTS set_interface_property interrupt_receiver ASSOCIATED_CLOCK clock_reset add_interface_port interrupt_receiver irq irq Input 32  the testing sopc project just has nios, onchipmem, 2x pio and this custom ip. both irq from the pio's go to nios and our ip.  sopc builder generates the verilog file which contains these section  //irq assign, which is an e_assign  assign cpu_0_data_master_irq = {1'b0, ..... unused set to 0 until ...  1'b0,  1'b0,  1'b0,  pio_1_s1_irq_from_sa,  pio_0_s1_irq_from_sa,  1'b0};  what is fine, but for our ip   //Sopc_Idle_0_avalon_slave_0_irq of type irq does not connect to anything so wire it to default (0)  assign Sopc_Idle_0_avalon_slave_0_irq = 0;  ups ? within sopc there are 2 ints connected. so we would expect here the same as done for the cpu  now, is there a chance without creating a datamaster to get access to these irq's ??? avalon interface specification is not clear here and the nios cpu has the irq's next to the data master.  Any idea how to setup such an avalon slave ?

[Altera_Forum]

Look at the bottom of the SOPC generated file and look at the simulation DUT instantiation, and you can find the names of all signals that are passed to your avalon module. I've never used an interrupt receiver, but I would image there is a signal that represents the irq's coming into your module. If the interrupt receiver has to be associated with an avalon slave, I believe the signals will be routed to your top-level avalon IP module inside the SOPC generated system file. 

 If not, and you need to declare a master, you have this option: Since you are really not doing anything with your interrupt receiver and just want to monitor the signals, you can create a simple dummy master that takes the two signals in, and add two exported output signals. In the dummy master module, assign the output signals to the irq input signals coming into the master. Then create two more inputs in your avalon slave IP. In your top level module, you will pass two declared wires to both your dummy master, and your avalon IP, so you can gain access to these irq signals in your avalon IP.  This is pure speculation, but hopefully it gives you ideas.

[Altera_Forum]

unfortunately only the nios has a DUT declaration. 

 the more i go through the altera docs the more i think that i will need a data master to gain access to the interrupt receiver functionality. a data master must be connected to an avalon slave, otherwise sopc builder will report an error. so this data master will only gain access to my avalon slave on its own avs (avalon valid slave) port without waitrequests and the nios will access via another avs with waitrequests to stall the nios until an irq occours.  so this sopc module will have these ports avm to get the interrupt receiver functions avs for the avs without waitrequest avs for nios with waitrequest.  

[Altera_Forum]

Here's a solution. You need to modify the generated SOPC file to add a 32 bit output port in the port list (perhaps called system_irq_out). 

 Search the file for "module system_0" (or whatever your system is named).  Add: "system_irq_out," in the port list.   Define the port: "output [31:0] system_irq_out;" anywhere where the other ports are defined.  Add: "wire system_irq_out = cpu_0_data_master_irq;" anywhere after the port list with the other wire declarations.  then you have exposure of these irq signals to your top-level module, which can be passed as a normal 32-bit input signal into your custom IP.  Yes....kind of sucks to have to do this everytime you re-build the system in SOPC builder, but it isn't too much work. Saves a lot of complexity for you. You have to re-adjust your thinking that this is a "hack". It isn't. The SOPC builder's generated verilog output for your system specification is just a verilog file, just like any other, as far as Quartus II's compiler is concerned. And it did 99.9999% of the work for you and did it very well. But, for your case, you need these IRQ signals, and SOPC builder doesn't have a feature that you can check to expose these signals. Perhaps it could be a feature request to be built into the next version of Quartus II.  It beats making another memory master, and slave just to obtain the irq signals. To me, that is a hack, rather than doing it in a straight-forward way.

[Altera_Forum]

MySupport showed my a solution that doesn't work here due to errors from sopc. 

so still waiting for new ideas. they added a master just for dummy purposes but this master needs to feed a slave.  Your hack is one way to go as a workaround, and i will go that way if there won't be a easy solution to keep the automatic generation process alive. such a hack can get forgotten and is gone when somebody else runs the generation scripts.  your hack should be done as follows assign Sopc_Idle_0_avalon_slave_0_irq = cpu_0_data_master_irq; instead of assign Sopc_Idle_0_avalon_slave_0_irq = 0;  Sopc_Idle_0_avalon_slave_0_irq is an input to my module so i do not understand why you create an output in the portlist as this input already exists and the cpu_0_data_master_irq has all informationen needed.  thanks anyway

[Altera_Forum]

<div class='quotetop'>QUOTE (MSchmitt @ Jul 24 2009, 04:30 AM) <{post_snapback}> (index.php?act=findpost&pid=23271)</div> 

--- Quote Start ---  your hack should be done as follows assign Sopc_Idle_0_avalon_slave_0_irq = cpu_0_data_master_irq; instead of assign Sopc_Idle_0_avalon_slave_0_irq = 0;  Sopc_Idle_0_avalon_slave_0_irq is an input to my module so i do not understand why you create an output in the portlist as this input already exists and the cpu_0_data_master_irq has all informationen needed.  thanks anyway[/b]  --- Quote End ---   No. You should define the irq signals input of your slave (perhaps called irqs) as an normal conduit input rather than a specialized interrupt receiver. In your top level module (of the project, not your IP&#39;s top level), define a wire like: "wire [31:0] system_irqs;"  In the instantiation of system_0 in your top level module, add the new port to obtain the irq information: ".system_irq_out(system_irqs),"  and pass it back into your IP by: ".irqs_to_the_Sopc_Idle_0_avalon_slave_0(system_irqs),"  and put some comments in your top-level module to document the manual changes that were necessary to add the port in system_0.v  This way, your IP is still a standard avalon MM IP that gets it&#39;s information the normal way by passing in the irqs info to one of it&#39;s ports from the top level project file.  And I disagree that what I am suggesting is a "hack". If there was an option to expose the irq signals with a check-box in SOPC builder, the code would be generated almost exactly as I describe. Unfortunately, there isn&#39;t. I am 100% positive this is the most direct and correct way to do this. I would call it a necessary "work around" due to SOPC builder not having an option to expose irq signals to the top-level module. That is why I said it might be a feature request for the next version of Quartus II.  P.S. Thanks for all the posts you make to help others. You are quite active!