cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
358 Views
Registered: ‎08-07-2019

AXI-Stream output, tvalid always = 0

Jump to solution

I am working on a very simple code:

#include <ap_int.h>

bool g_grab_prev = false;
bool g_debug_dummy = false;

ap_uint<72> pack_datamover_command(ap_uint<4> tag, ap_uint<32> saddr,
        bool eof, bool type) {
#pragma HLS INLINE

    ap_uint<72> cmd = 0;

    cmd.range(67, 64) = tag;
    cmd.range(63, 32) = saddr;
    cmd[30] = eof;
    cmd[23] = type;
    cmd.range(10, 0) = C_BYTE_TO_TRANSFER;
    return cmd;
}

void control_fsm(bool grab, ap_uint<72> *m_axis_command) {
#pragma HLS LATENCY max=0
//#pragma HLS INTERFACE ap_ctrl_none port=return
#pragma HLS INTERFACE axis register both port=m_axis_command
#pragma HLS INTERFACE ap_none port=m_axis_command_valid

    if (!g_grab_prev and grab) {
        *m_axis_command = pack_datamover_command(0,
                0x10000000 + g_debug_dummy, 0, 1);
        g_debug_dummy = !g_debug_dummy;
    }
    g_grab_prev = grab;
}

I put that into a block design in Vivado (as below), along with a FIFO and a RTL block, which did not interract with the HLS block:image.png

I wrote a simple VHDL testbench and underwent a simulation, however, the result is not as expected. The tvalid for m_axis_command never went to 1:

image.png

The weird thing was that when I isolated the HLS block and used a very similar testbench, tvalid is correct:

image.pngimage.png

Also, when I modified the testbench which toggled ap_start every 20 clock cycles, tvalid also behave normally:

image.png

May I ask why would that happened?

For your reference, the project is attached.

Thank you very much.

1 Solution

Accepted Solutions
Highlighted
Contributor
Contributor
131 Views
Registered: ‎08-07-2019

Re: AXI-Stream output, tvalid always = 0

Jump to solution

Thanks for all the support from FAE.

For the testbench, it has been figured on that it was the problem with clock process:

 

process begin
    ap_clk_0 <= not ap_clk_0;
    wait for 5ns;
end process;

 

 

process begin
    wait for 5ns;
    ap_clk_0 <= not ap_clk_0;
end process;

The second one works but the first one doesn't. It is because if the first one is used, the transition of other signals is right in the rising edge of clock as what I've written on the testbench.

 

Later on, I found that the code works simulation but not in the hardware. I figured out that it was because my HLS code depends global variables to be reset to default value at startup. However, it didn't because I did not add a "config_rtl" command in solution setting to reset all signals.

 

View solution in original post

0 Kudos
2 Replies
Highlighted
Explorer
Explorer
252 Views
Registered: ‎06-25-2010

Re: AXI-Stream output, tvalid always = 0

Jump to solution

HI,  I'll handle this case by  local  channel on feild or by email and webex. And I'll shared the solution to the forum friends. Thanks.

0 Kudos
Highlighted
Contributor
Contributor
132 Views
Registered: ‎08-07-2019

Re: AXI-Stream output, tvalid always = 0

Jump to solution

Thanks for all the support from FAE.

For the testbench, it has been figured on that it was the problem with clock process:

 

process begin
    ap_clk_0 <= not ap_clk_0;
    wait for 5ns;
end process;

 

 

process begin
    wait for 5ns;
    ap_clk_0 <= not ap_clk_0;
end process;

The second one works but the first one doesn't. It is because if the first one is used, the transition of other signals is right in the rising edge of clock as what I've written on the testbench.

 

Later on, I found that the code works simulation but not in the hardware. I figured out that it was because my HLS code depends global variables to be reset to default value at startup. However, it didn't because I did not add a "config_rtl" command in solution setting to reset all signals.

 

View solution in original post

0 Kudos