cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Observer
Observer
368 Views
Registered: ‎06-10-2019

AXI4M_bus_port deadlock with ap_uint<32> payload

It seems Vivado HLS generates inproper RTL when reading/writing to an AXI4M_bus_port with an ap_uint as payload. I've made some real efforts to keep my code minimal, so I hope this will be useful to diagnose the problem.

In the Vivado HLS user guide, under "SystemC AXI4 Master Interface", it is specified that any type that is a multiple of 8-bits should work as payload of AXI4M_bus_port, and the example given there even uses an sc_fixed<32,8> payload. However, I notice that this is not functional.

In the attached ZIP, I have two Vivado HLS projects generated using the exact same code, with only the payload of the AXI4M_bus_port as a difference, as can be verified with a simple git diff:

antho:~/OneDrive/Desktop$ git diff --no-index uint32_t_32-1024-0-1-1-0/filtering0.cpp ap_uint32_32-1024-0-1-1-0/filtering0.cpp

antho:~/OneDrive/Desktop$ git diff --no-index uint32_t_32-1024-0-1-1-0/filtering0.h ap_uint32_32-1024-0-1-1-0/filtering0.h
diff --git a/uint32_t_32-1024-0-1-1-0/filtering0.h b/ap_uint32_32-1024-0-1-1-0/filtering0.h
index 347a8fa..f986549 100644
--- a/uint32_t_32-1024-0-1-1-0/filtering0.h
+++ b/ap_uint32_32-1024-0-1-1-0/filtering0.h
@@ -13,7 +13,7 @@ using namespace std;
#include <inttypes.h>
#include <systemc>

-typedef uint32_t axi_data_t;
+typedef ap_uint<32> axi_data_t;
#define AXI_BITWIDTH 32
#define NUM_AXI_TRANSFERS 1024
#define PARTITION_ARRAY 0
antho:~/OneDrive/Desktop$

This code performs a pipelined write and read in a loop on the AXI4M_bus_port.

I have also provided a Vivado simulation of the IPs generated by Vivado HLS ; they are in the ap_uint32_32-1024-0-1-1-0/vivado_sim and uint32_t_32-1024-0-1-1-0/vivado_sim directories of the ZIP file. For each Vivado project, I have added the RTL files generated by Vivado HLS under filtering0/solution1/impl/verilog.pcore , as well as two basic hand-written VHDL wrappers to stimulate the AXI signals: sim-top.vhd and dummy_axi_slave.vhd. Note that, although the AXI signals are stimulated by my dummy_axi_slave.vhd wrapper, I have been able to confirm the same simulation behavior using the AXI VIP.

The screenshots below show the results: for the project where the payload is ap_uint<32>, the IP generated by Vivado HLS tries to perform a read and then blocks, but, for the project where the payload is uint32_t, the IP generated by Vivado HLS performs reads and writes without any problem.

I believe this is a Vivado HLS bug ; my two Vivado HLS projects should definitely be functionally equivalent.

Simulation for project with ap_uint<32> paylaodSimulation for project with ap_uint<32> paylaod

Simulation with ap_uint<32> payload.

 

Simulation with uint32_t payloadSimulation with uint32_t payload

Simulation with uint32_t payload.

0 Kudos
3 Replies
Highlighted
Observer
Observer
242 Views
Registered: ‎01-12-2012

Any update on your end ?

0 Kudos
Highlighted
Observer
Observer
231 Views
Registered: ‎06-10-2019

Well, we ended up using a uint32_t type instead. This is not ideal because, if we wanted a 128-bit AXI bus, I'm not sure how we would express that because there is no integer type (that I know of) for a 128-bit value.

This does not answer this topic's question, though, unfortunately.

0 Kudos
Highlighted
Newbie
Newbie
204 Views
Registered: ‎07-29-2020

Looks there is some problem with HLS. By looking at the recent Question, we will notify that many people struggling with the same issue.

I have the same problem, but for me by using uint32_t is not responding, as well. Would you please check out my question!

https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/AXI-interface-m-axi-with-DDR/td-p/1134107

 

TNX,

0 Kudos