Hello, i would like to know, how I can use interrupts in conjunction with a Cyclone V. (Comparative Avalon) Do you probably have an example for me? I would like to trigger an interrupt using a button. Thanks! Greetings

Yes you can as long as you use a later version of the tools. I forget when they were introduced but 12.1 SP1 or later should have the feature. The HPS has 64 bits of interrupt lines that originate in the FPGA fabric that are sent to the HPS. These interrupt lines connect to the generic interupt controller (GIC) in the MPU subsystem. The MPU subsystem chapter in the device handbook contains the mapping of the FPGA interrupt lines to GIC interrupt numbers, off the top of my head FPGA interrupt [0] connects to GIC interrupt [72]: http://www.altera.com/literature/hb/cyclone-v/cv_54006.pdf When you connect the PIO to the HPS, use the lightweight HPS-to-FPGA bridge for the memory mapped accesses to the PIO. That lightweight bridge is for accessing CSRs like the PIO. Also the FPGA-to-HPS interrupts are 64-bit but Qsys only supports 32-bit interrupts. As a result the HPS exposes two interrupt receivers, one for the lower 32 bits and the other for the upper 32 bits. Alteratively you can also configure unused HPS I/O as GPIO and use them instead of the FPGA fabric. Each HPS GPIO is capable of generating interrupts as well.

I am using 13.0sp1 and when I enable the 64 fpga2hps interrupt lines, I can't figure out how to make a connection to these interrupt lines. There is no interface created in Qsys and the generated soc_system.v file does not bring these interrupts out to a port. It does create two internal wires: wire [31:0] hps_f2h_irq0_irq; // irq_mapper:sender_irq -> hps:f2h_irq_p0 wire [31:0] hps_f2h_irq1_irq; // irq_mapper_001:sender_irq -> hps:f2h_irq_p1 and these wires do connect to the hps instantiation, but I don't see how to make an external connection to any of these lines. Compiling the design with these turned on does generate an extra warning: Warning (11713): The configuration of the Hard Processor Subsystem (HPS) within this design has changed. The Preloader software that initializes the HPS requires an update. Using hps_isw_handoff/soc_system_hps/, run the Preloader Support Package Generator to update your Preloader software This warning seems to indicate that the preloader is responsible for setting up these connections, but I'm not sure how to make the connection on the fpga side? Is there another component that needs to be instantiated in qsys? Is there another setting that needs to be done in the hps parameter settings? Is this another feature that is not available with the current tools but will be available in a future release (13.1)?

Interrupt wiring is a little different in Qsys. Over on the right side of your system you should see another patch panel where you can type numbers into them. The numbers normally represents interrupt priority but in the case of the HPS they represent which interrupt bit you are connecting a perheriphals interrupt to out of the group of 32. The interrupt priority is determined by how the generic interrupt controller settings inside the HPS and not the numbers you choose in Qsys, the numbers are just determining connectivity.

Yes, of course. I see the interrupt connection you're talking about in Qsys. Thanks.

Hello, I'm currently trying to make use of the FPGA -> HPS interrupt lines as well and I'm running into issues. In summary, I have interrupts coming in from the FPGA on FPGA_IRQ0 and FPGA_IRQ1 (GIC interrupts 72 and 73) and an IRQ handler registered for these same lines. However, I never see the interrupts appear in Linux. See the below cat /proc/interrupts (my module is "fpgaint"): CPU0 CPU1 29: 15752236 15740759 GIC twd 72: 0 0 GIC fpgaint0 73: 0 0 GIC fpgaint1 147: 47023 0 GIC eth0 160: 1 0 GIC dwc_otg, dwc_otg_hcd:usb1 171: 2052 0 GIC dw-mci By peeking around the ARM GIC registers, I verified that the triggering is set properly according to the nodes I placed in the device tree (edge triggered) and that the interrupts are in fact enabled. So at this point I'm confident that the Linux setup and the ARM GIC setup are correct. I've read the GIC interrupt status register as well and never see my interrupt lines go high. I'm currently working with our hardware engineer to verify the interrupt lines are going high from the FPGA side using SignalTap. I noticed in the above discussion that after enabling these interrupt lines in the FPGA build, the preloader needed to be regenerated. I looked through the handoff files and I don't see anything that corresponds to these interrupt lines. Overall, I have the below questions: What exactly needs to be done at the initialization stage by the preloader to enable these interrupt paths? Which variables get modified in the handoff files when these interrupt lines are enabled (so I can trace to ensure my preloader is handling this)? Is there anything else that comes to mind that might be going wrong here? Do some bridges need to be released from reset? I don't know anything about FPGA code but is there any special way that these interrupts have to be generated? Or is simply pulsing that line sufficient for edge triggered configuration? I appreciate any guidance either of you could give. Thanks, -Chris

Cyclone V - Interrupt Handling | Altera Community

14 Replies

Altera_Forum
Honored Contributor
11 years ago
I realized I updated the Rocketboards mailing list but not this forum post with my solution to the problem (thanks for calling me out Bram!).

I wrote the software side of things, however, I didn’t write the FPGA code that triggers the IRQ lines.

It was my desire to be able to receive FPGA -> HPS interrupts in user space, so I wrote a simple module that accomplishes that. The module creates “fpgaint” devices under /dev for each “fpgaint” node present in the device tree that has interrupt information. A user space program can then open these devices and poll/read them to get interrupt triggers. I attached a patch that adds the module I created to the 3.9 Linux tree as well as 3 example nodes to the device tree to create the IRQ devices for FPGA_HPS IRQs 0, 1 and 2. Note that this module is very simple and has a pretty extreme limitation in that only 1 user space program can receive these interrupts from a fpgaint device node at a time. If someone wanted to expand the module so that more programs can wait on the fpgaint device node and have them all wake up at each interrupt, that would be excellent. ;) Also note that this patch has a bunch of debugging printks that you should probably remove if you want to actually use this stuff.

I also attached a little test program that shows how to capture these interrupts in user space.

In order to verify this stuff, I had our FPGA guy tie the FPGA_IRQ2 line to a simple register that I can write high or low to toggle the interrupt line. Then after insmoding the fpgaint module (with a device tree node for that interrupt line present), I ran the fpgaint_test.c program on the device created for that interrupt line (/dev/fpgaint2 according to my device tree node setup). I then performed the FPGA register writes to toggle the line and saw my test program receiving the interrupts in user space.

The FPGA guy said this with respect to how we tested the interrupt interface: I routed the GPIO output register (from the HPS) to the IRQ lines. You were able to write to bits on that register and create an interrupt.

Hopefully this is helpful to the folks on the forum.
fpgaint.zip4 KB
Altera_Forum
Honored Contributor
11 years ago
Have there been any updates to your FPGAINT driver? It seems as though whenever I get a valid interrupt, the fgpaint_irq_handler gets repeatedly called and locks up my system. (I end up in an infinite loop with the "FPGA interrupt module: fpgaint_irq_handler called" output message on the console.) I am not a driver guru by any means but is your driver an edge or level triggered ISR? Also, it appears that the fpgaint_irq_handler process calls wake_up_interruptable(); Can you offer any assistance in understanding the connection between that call and my "user space" ISR?

Thanx in advance.
Altera_Forum
Honored Contributor
11 years ago
Hi there, for those of you who are having trouble getting interrupts from the FPGA through to Linux, here are some pointers:

1. Qn: I've written a custom Linux driver to catch interrupts on the FPGA IRQ line with GIC offset of 72. I see no interrupts happening. What is going on??

Ans: If you are using a PIO core in Qsys to generate an interrupt, you need to manually enable the interrupts! Otherwise, the PIO core will never ever generate any interrupts (http://www.altera.co.uk/literature/ug/ug_embedded_ip.pdf pg.12-3) The Interrupt bit mask register (fancy name for the register to enable interrupts) is on offset 0x8 w.r.t PIO register base address.

2. Qn: The IRQ handler gets repeatedly called! This locks up the system as you cannot do a normal CTRL+C to the terminal since it is loaded as a Linux Kernel Device driver.

Ans: By default, interrupts on the ARM are level based (logic high) and not edge triggered. When an interrupt is generated by a PIO core, you need to reset the interrupts on the PIO core manually or else the interrupt line will stay high forever (you can confirm this via SignalTap). Since the IRQ line from the FPGA is always high unless you reset it, the ARM gets interrupted repeatedly!
The IRQ reset register is located on offset 0xc. Writing any value to this register would reset the interrupts on the PIO core and the IRQ signal would return back to logic low.

3. You can write to the IRQ bit mask register and IRQ reset register of the PIO core via SystemConsole. A more elegant method is to have your custom kernel driver write to the PIO registers directly (see http://zhehaomao.com/blog/fpga/2013/12/29/sockit-4.html)!

4. Qn: How do you make a custom Linux Kernel Driver??

Ans:
-Check out these great tutorials to get you started: http://www.tldp.org/ldp/lkmpg/2.6/html/lkmpg.html ,http://zhehaomao.com/blog/fpga/2014/05/24/sockit-10.html
-You can only build your custom Linux Kernel Driver on a Linux machine
-Set up your terminal environment variables to point to the correct cross compiler: export PATH=.../altera-linux/linaro/gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux/bin:$PATH
-Locate the Linux kernel source code that you used to build your Linux kernel. If you are using a Yocto build flow, the path looks like: .../yocto/build/tmp/work/socfpga_cyclone5-poky-linux-gnueabi/linux-altera-dist-1.0-r1/linux-socfpga
-The above step is crucial as Linux really really does not like it if you use a different kernel version to build your driver. For example, if you are using a 3.12 linux source code to build your kernel driver and try to load that kernel module on a 3.9 Linux version, it will throw errors that are extremely confusing to debug.
-Use insmod <your kernel driver.ko> to load your custom Linux driver to your Linux kernel
-Likewise, use rmmod <your kernel driver.ko> to unload your custom Linux driver
-I have a simple example project where a custom written Linux driver registers interrupts from the FPGA user buttons. PM me for the Quartus Project, custom linux driver code and Makefile if you would like a simple example to get you started quickly.

5. One last tip, Linux kernel driver development is very different from that of a userspace linux program. It can get very frustrating at times! Hell, it took me 2 full days just to set up my environment to build a simple hello_world kernel driver!! But persevere through and don't be discouraged!
Altera_Forum
Honored Contributor
11 years ago
On "2. Qn:": GIC may be programmed to Edge mode and you may not hold IRQ line from the FPGA in 1 longer than 1 tact.
And clearing of GIC pendig bits not clear IRQ line from the FPGA !
In Level mode interrupt handler MUST send a command to FPGA with clearing IRQ demand: GIC don't know about your hardware process.

Forum Discussion

Cyclone V - Interrupt Handling

14 Replies

Recent Discussions

Will serialization factor of 6 in LVDS serdes IP be supported in the future on Agilex5?

System PLL of Agliex5 PCIE example design cannot be locked after configuration

JTAG Chain Broken on Agilex 7-I Dev Kit

Request for Cyclone V Pinout File Information

Cyclone 10 LP's Extended Industrial parts