Custom IRQ stuck

Custom IRQ stuck

by Luca Joss -
Number of replies: 4
Hello,

We have a very simple IRQ for our parallel port which is triggered when we write at a given address and the iInterruptMask is enabled as seen in the following picture :

VHDL section of Parallel Port triggering IRQ

We simulated with ModelSim to check if the IRQ was indeed set to '1' when all the conditions are met :

ModelSim testing IRQ of Custom Parallel Port

But when we trigger it with a small C code, it seems to get stuck. This was seen by having a few printf before the while loop, the code never reached the loop :

Code C which gets stuck when IRQ is triggered

Are we implementing something, such as setting the IRQ to '1' only for one cycle ?

Here are the Qsys and system.h :

Qsys showing IRQ ID

Qsys showing Custom Parallel Port IRQ Sender

system.h file showing IRQ ID of Custom Parallel Port
In reply to Luca Joss

Re: Custom IRQ stuck

by Philipp Thomas Nicolai Schuler -

As I can see in your C code, you don't take into account the 32bit addressing, so you have to multiply by 4 the register addresses (for instance 4*5 and 4*7 for IRQ enable and trigger)

In reply to Luca Joss

Re: Custom IRQ stuck

by René Beuchat -

Hello,

it^s not a good idea to have only 1 clock cycle interrupt as explained during the class.

On the NIOS ii 2 internal registers, one as a mask, one for iPending with onebit number corresponding to the interrupt request level (as connected on QSYS.

No memorization done at the level, iPending activated if pin Irq active and iMask activated.

Thus you have to memorize the request until acknowledged by the code in the ISR, not before, not after.

In your code you have to remove the i

  • else
  •      irq <= '0';

Then irq wil stay activated until you access the IP in the ISR.

What is the size of your programmable interface 32 bits? then your code using IORW and IOWR is ok, if not you have to use the IO_rd32direct or IO_wr32direct macro.

Best.

RB



In reply to René Beuchat

Re: Custom IRQ stuck

by Luca Joss -

Hello,

Thank you for the reply, keeping the IRQ active until we access the IP in the ISR fixed the issue.

We can now measure the latency by setting a pin of our Parallel Port to '1' when we trigger the IRQ, and set it to '0' at the beginning of the IRQ_handler. But we seem to be getting high values for the latency, around 1 microsecond.

The modified Parallel Port :

Modified PPort


The modified C code :
Modified C code
Modified alt_irq_handler (We clear the pin 1 of our Parallel Port) :
Modified irq_handler

Saleae measurement :
Saleae Measurement
In reply to Luca Joss

Re: Custom IRQ stuck

by Sahand Kashani-Akhavan -

Your code works, but I want to point out something that's a bit inefficient and doesn't accurately capture the circuit you intend to create.

You are using if statements to multiplex the address bus in your slave, but you are doing a sequence of if-statement rather than an if-elseif chain. If you do a sequence of if-statements, the tools can think that the first if-statement could be true, and the second if-statement can be true, ..., whereas if you write an if-elseif statement for the addresses, then you are making it clear that only one of the branches will have an effect. Some tools can see that you are testing the same signal in all if-statements and correctly transform this internally into mutually-exclusive conditoins, but not all tools are smart enough.

The best thing here is to use a case statement in VHDL as it perfectly describes what you intend to do: A multiplexor on the address where only one outcome is possible.