Avalon Slave IP with Interrupt Receiver

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.

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.

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.

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

<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!