← ZCU104, PYNQ v3.0 →
How to write through custom axilite interface written in VHDL:
in v2.6: controller = overlay.hier_0.my_ip.axi_s
controller.write(0x00,0x81)
in v2.7: controller = overlay.hier_0.my_ip
controller.write(0x00,0x81)
in v3.0 both are not working, showing
AttributeError: Could not find IP or hierarchy axi_s in overlay
or if written like v2.7
AttributeError: Could not find IP or hierarchy write in overlay
What is actually happening? how to write to the registers?
Mizan
Hi Mizan,
There have been changes regarding how we are processing the overlay metadata in v3.0, which might have affected the parsing of the custom-packaged IP. Is it possible for you to share your hwh file so I can have a look?
All the best,
Shane
Unfortuantely i can’t share the hardware file for this, but i will make compact project with similar IP and then share hwh file.
That would be very helpful, thank you.
When looking through the IP dict / Hierarchy dict is the IP listed at all?
All the best,
Shane
Yes it is there with showing mem_id and memtype and so on…
In the ip_dict, is the driver field populated for my_ip? What about in the hierarchy_dict?
Hopefully when I can see the minimal example it will clear things up.
Many thanks,
Shane
Sorry for the delay. I have attached the hwh file.test.hwh (222.2 KB)
I tried to include bitstream as well but it seems I can’t attach that big file.
here are the contents of the hierchy directory:
{'hier_0': {'ip': {},
'memories': {},
'hierarchies': {'my_ip': {'ip': {},
'memories': {},
'hierarchies': {},
'interrupts': {},
'gpio': {},
'fullpath': 'hier_0/my_ip',
'device': <pynq.pl_server.embedded_device.EmbeddedDevice at 0xffff778bcca0>,
'driver': <function pynq.overlay.DocumentHierarchy(description)>,
'overlay': <pynq.overlay.Overlay at 0xffff6d9f79d0>}},
'interrupts': {},
'gpio': {},
'fullpath': 'hier_0',
'device': <pynq.pl_server.embedded_device.EmbeddedDevice at 0xffff778bcca0>,
'driver': <function pynq.overlay.DocumentHierarchy(description)>,
'overlay': <pynq.overlay.Overlay at 0xffff6d9f79d0>},
'hier_0/my_ip': {'ip': {},
'memories': {},
'hierarchies': {},
'interrupts': {},
'gpio': {},
'fullpath': 'hier_0/my_ip',
'device': <pynq.pl_server.embedded_device.EmbeddedDevice at 0xffff778bcca0>,
'driver': <function pynq.overlay.DocumentHierarchy(description)>,
'overlay': <pynq.overlay.Overlay at 0xffff6d9f79d0>}}
Contents of IP_dict:
'hier_0/my_ip': {'type': 'xilinx.com:module_ref:pipeline_top:1.0',
'mem_id': 'S_AXI_CTRL',
'memtype': 'REGISTER',
'gpio': {},
'interrupts': {},
'parameters': {'C_S_AXI_CONTROL_ADDR_WIDTH': '8',
'C_S_AXI_CONTROL_DATA_WIDTH': '32',
'Component_Name': 'design_1_pipeline_top_0_1',
'EDK_IPTYPE': 'PERIPHERAL',
'C_BASEADDR': '0x80000000',
'C_HIGHADDR': '0x80000FFF',
'DATA_WIDTH': '32',
'PROTOCOL': 'AXI4LITE',
'FREQ_HZ': '148504983',
'ID_WIDTH': '0',
'ADDR_WIDTH': '8',
'AWUSER_WIDTH': '0',
'ARUSER_WIDTH': '0',
'WUSER_WIDTH': '0',
'RUSER_WIDTH': '0',
'BUSER_WIDTH': '0',
'READ_WRITE_MODE': 'READ_WRITE',
'HAS_BURST': '0',
'HAS_LOCK': '0',
'HAS_PROT': '0',
'HAS_CACHE': '0',
'HAS_QOS': '0',
'HAS_REGION': '0',
'HAS_WSTRB': '1',
'HAS_BRESP': '1',
'HAS_RRESP': '1',
'SUPPORTS_NARROW_BURST': '0',
'NUM_READ_OUTSTANDING': '1',
'NUM_WRITE_OUTSTANDING': '1',
'MAX_BURST_LENGTH': '1',
'PHASE': '0.0',
'CLK_DOMAIN': 'design_1_clk_wiz_0_0_clk_out1',
'NUM_READ_THREADS': '4',
'NUM_WRITE_THREADS': '4',
'RUSER_BITS_PER_BYTE': '0',
'WUSER_BITS_PER_BYTE': '0',
'INSERT_VIP': '0'},
'registers': {},
'driver': pynq.overlay.DefaultIP,
'device': <pynq.pl_server.embedded_device.EmbeddedDevice at 0xffff778bcca0>,
'state': None,
'bdtype': None,
'phys_addr': 2147483648,
'addr_range': 4096,
'fullpath': 'hier_0/my_ip'},
It looks like your ip is being treated as a hierarchy rather than an IP in the hierarchy_dict. I believe I know what the issue is here, but I will need to investigate a bit further.
In the meantime, when packaging your IP, can you change the library name from module_ref to something else and see if that helps?
All the best,
Shane
I have not put the library name. I think it comes automatically when a module is imported in block design or might be I don’t exactly know how to change it. So, you can share what to change in order to do so 
Ah okay thanks, can you talk me through how you made the IP and imported it into the block design?
All the best,
Shane
It’s written in vhdl and import as module in block design. As far as i can understand module_ref is automatically added when vhdl code is imported as module.
Edit: There is nothing but an axi-lite component.
@stf And, another confirmed bug I have found in v3.0 ( at least from my side). I am saying confirmed as I have tested it with v2.6 also. before telling what is it I want to give a brief overview of my workflow:
generally, I open a python notebook and load the overlay.
If there is any problem on the hardware side, I generate the bitstream file again and replace the bit hwh files in pynq folder.
Then I click kernel → restart and clear output
after that I run the program again. Bitstream gets loaded and run okay.
But in v3.0, the overlay description of same bitstream file name doesn’t update after the first load. the description is loaded from the first time. For every later time, it loads from somewhere in the cache, which was loaded the first time (it’s just my opinion).
checked with several things, like completely deleting both bit and hwh files then copying new files, closing jupyter notebook, restarting kernel, but nothing works, it loads the previous hwh content (which I believe is stored somewhere). Even from another notebook, if i load the same bitstream, it still comes with the previous hwh description. Only restarting is making new changes after load.
At first, I thought it is problem with the sd card or something from my side. Then I load v2.6 and tested it with the same sd card. Everything looks fine completely. Again I loaded v3.0 and the same things started happening.
Thanks Mizan,
I’ll look into the caching issue also. You’re right there is some caching that happens under the hood and I guess in your case it is getting stuck. It is supposed to clear whenever the bitfile changes.
To manually clear the cache can you try:
from pynq import PL
PL.reset()
All the best,
Shane
Hi Mizan,
For your custom axi interface issue would you mind testing out the following for me.
On your board, in a jupyter lab terminal, can you try and run the following command:
python3 -m pip install git+https://github.com/STFleming/PYNQ-Metadata.git@partial_hier_fix
Then restart the notebook and see if you can access the registers of the IP.
If this works can you let me know and I’ll do some more testing on it and try and get a fix up.
Many thanks for reporting this.
All the best,
Shane
After installing pynqmetadata 0.1.0 and restarting the notebook, I was going to write ‘it is not working’. But then I restarted the board, it seems working okay, it was just caching issue again.
About the caching issue, you can reproduce it very easily with a zcu104 board and precompiled image for zcu104.
Thanks Mizan,
I’ll do some more testing on this and let you know when the full fix is up.
For the caching issue, did you still have to restart the board even after running?
from pynq import PL
PL.reset()
I’ll look into the caching issue today, not quite sure we are seeing the same situation on our boards but I’ll try to recreate your issue and get back to you.
All the best,
Shane
It does work with adding this. It didn’t need to reboot anymore.
Thanks for fixing this. I have several RTL modules with axi interfaces added to my design that were being interpreted as hierarchies.
For others, just update from the main PYNQ-Metadata repo since it looks like it has been merged.
python3 -m pip install git+https://github.com/Xilinx/PYNQ-Metadata
Thanks.
The fix should be up on PyPi now also, so the following should do the trick too.
python3 -m pip install pynqmetadata --upgrade
All the best,
Shane
Hi Shane,
Is this change included in the pre-built v3.0.1 metadata file? If not will there be a v3.0.2?
Thank you,
-Fred
Hi Fred,
This change isn’t in the 3.0.1 images. The following image will include it; however, we have yet to set a schedule for when that will be released. In the meantime, the fix is to pip install the latest pynqmetadata version on the board.
Thanks,
Shane