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)
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
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 :
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.