04-10-2018 01:33 AM
JTAG to AXI Master v1.2
What I do:
create_hw_axi_txn rd_txn [get_hw_axis hw_axi_0] -address 270000000 -len 8 -type read run_hw_axi [get_hw_axi_txns rd_txn] report_hw_axi_txn [get_hw_axi_txns rd_txn]
What I expect:
create_hw_axi_txn rd_txn [get_hw_axis hw_axi_0] -address 270000000 -len 8 -type read rd_txn run_hw_axi [get_hw_axi_txns rd_txn] INFO: [Labtoolstcl 44-481] READ DATA is: 0000000000000000000000000000000000000000000000000000000000000000 report_hw_axi_txn [get_hw_axi_txns rd_txn] 270000000 00000000 00000000 270000008 00000000 00000000 270000010 00000000 00000000 270000018 00000000 00000000
What I actually get:
create_hw_axi_txn rd_txn [get_hw_axis hw_axi_0] -address 270000000 -len 8 -type read rd_txn run_hw_axi [get_hw_axi_txns rd_txn] INFO: [Labtoolstcl 44-481] READ DATA is: 0000000000000000000000000000000000000000000000000000000000000000 report_hw_axi_txn [get_hw_axi_txns rd_txn] ffffffff 00000000 00000000 100000007 00000000 00000000 10000000f 00000000 00000000 100000017 00000000 00000000
See the wrong address range and that it seems like address' above 4GB range can't be displayed correctly.
Nothing critical since I get back the correct data and can work with it, but maybe sth. for a small bugfix in future versions.
04-17-2018 01:01 PM - edited 04-17-2018 01:02 PM
When using the AXI4 protocol, the reading sometimes cross a 4K boundary and ends up accessing the wrong address.
Could you try to configure your JTAG to AXI IP in AXI-Lite mode (by selecting the AXI4LITE protocol in the JTAG to AXI Master IP customization GUI - protocol field)?
That should read out the correct data.
04-18-2018 12:51 AM - edited 04-18-2018 12:56 AM
it reads out the correct data and accesses the correct addresses so the data I get back are what I expect it to be at that addresses.
I believe it is rather a matter of correctly displaying the address range within the TCl console, since the core is working just fine.
So in my example I receive the correct data from addresses 270000000 and above, they are just misleadingly displayed as ffffffff and above.
I just wanted to make you guys aware of this and maybe if some fellow engineers wonder as well about the address range and they find this post, they know that it's just a display mistake but the data is correct (which is probably what mainly matters).
04-19-2018 01:53 PM
Thank you for the clarification! Would you be able to share the design where you detected that (be sure to remove any IP you have there and that you don't want to be shared)?
I would like to go ahead and test it here too, as well as open and internal Change Request and send it to the Vivado and IP developers to fix it in the next release.
09-20-2018 02:49 AM - edited 09-20-2018 02:51 AM
sorry I didn't reply to your last request.
Usually I receive notification e-mails when somebody posted sth. but for some reason this time that didn't happen. Or I simply mistook the mail for spam, in that case, my bad.
Concerning your request:
Any design with a JTAG2AXI core with access to a memory range above 4G should do it.
You could take the xapp1171 example design and add (e.g.) 0x2_0000_0000 to all the addresses. Than add the JTAG2AXI core and try to read out sth. from the BRAM. That should be sufficient to showcase the display bug :)