search

Xilinx / PYNQ-Metadata

PYNQ-Metadata provides an abstract description of reconfigurable system designs.
BSD 3-Clause "New" or "Revised" License
7 stars 7 forks source link

HwhFrontend doesn't register interrupt ports #15

Closed TRnhld closed 9 months ago

TRnhld commented 10 months ago

In hwh_frontend.py there is no check for type of INTERRUPT scalar port.

The Parser registers scalar port types of "rst" and "clk". (line 336f. for external and line 432 for internal signals) There should also be a check for if p.get("SIGIS") == "INTERRUPT".

STFleming commented 9 months ago

Thanks for raising this! However, I think I might need a bit more details on this issue.

As it stands interrupt lines are figured out when constructing the interrupt dict view onto the metadata. It walks backwards from interrupt controller IP into the PS. This means that currently interrupts are treated like regular scalar ports when parsing the hwh. We could add an extra port type for interrupt like we have for clk and rst, but it would be good to understand if there is a specific bug that triggered this request.

TRnhld commented 9 months ago

You are right, when I use an Interrupt controller - it gets some data about interrupt. I need to have a look further into this to provide more information.

So far i noticed, there is a difference of connecting the concatinated interrupts directly to the IRQ_F2P Port of Zynq-PS (empty list of interrupts in overlay object) and using an interrupt controller (some interrupts are registered).

I'll update this issue as I find out further information.

TRnhld commented 9 months ago

Ok, here is some further Information I discovered ...

This Issue regards to implementations without using interrupt controller. Such implementation will not parse any interrupts. Since documentation of PYNQ uses the Interrupt controller, I'll take that as my own fault.

The current design using AXI Interrupt Controller seems to find Interrupts correctly in ip_dict. But I'm getting a warning regarding interrupt on first call on object with interrupt.

image

Note: The warning is just created on first called opject with interrupt. Different objects (like o.axi_iic_0 or o.qspi_master_hier.axi_quad_spi) result in the same warning.

I tracked that warning down to its root. - ended up at function call pynq.uio.get_uio_device("41600000.i2c"). This function tries to open files from folder "/sys/class/uio" to get the actual path of the interrupt device. For some reason, this folder does not exist with my system...

I will close this Issue, since it's not related to this repository.