UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
4,748 Views
Registered: ‎10-24-2016

VDMA not working as expected with SOF in TUSER(0)

Hi to all, 

 

I am facing problems to start correctly a data transfer to VDMA core. I am using external SOF through TUSER(0). Data is passed from logic to VDMA core through a own IP which controls all AXI 4 Stream signals required. Data is sent from VDMA to DDR3 memory. MM2S side is not used on VDMA, only S2MM.

 

I would need to confirm if I am doing something wrong because VDMA is always busy after starting a transfer, and no data is passed to DDR3 memory ( zero data passed).

 

I explain a bit the system. Firstly I will explain PL side and then PS side.

 

A custom IP Core catch data from an image sensor and present them to VDMA AXI Stream interface every 120ns. This data is 32-bit depth. To carry out this process, the steps I follow are:

1 - Start the transfer with a pulse on TUSER(0) signal on Axi Stream interface.

2 - TVALID signal is activated every time valid data is present on TDATA (31 downto 0) of my core.

3 - TLAST signal is activated during one pulse every time a complete line has been sent to VDMA.

 

To simplify the system up to get it working, I have created a simple "pixel_generator" which increments a variable and send it by TDATA to VDMA. The "Fake frame" I am sending to VDMA now is 10x10 pixels, every pixel is 4 bytes. I paste a screenshot showing signals created by my CORE. These signals are connected to S2MM interface of VDMA.

 

As you see, TUSER(0) is activated when the first pixel is ready, and TLAST signal is activated every 10 pixels (one complete line on my "fake frame generator".

Start_Frame.png

At the end of the frame (after 100 pixels (10 lines x 10 pixels)) TLAST is asserted for the last time when the last pixel is ready to be sent to VDMA.

 

End Frame.png

From the processor side I paste you my VDMA configuration in XPS (only configured to get one frame because my idea is not to save frames continously, only to save one frame when required. I could say, working as a photo camera):

 

VDMA options.png

And these are the parameters configured on S2MM side ( the only one I use):

 

S2MM.png

 

So my first question is:

 

1. Is this configuration correct?? Is my handshaking correct to getting VDMA work??

 

On the other side, in Microblaze code I do the following:

 

 

This function is called the first:

 

static int InitializeVdma  ()
{
	int Status;

	Config = XAxiVdma_LookupConfig(VDMA_DEVICE_ID);
	if (!Config) {
		xil_printf("No VMDA instance has been found\n\r");
		return XST_FAILURE;
		}

	Status = XAxiVdma_CfgInitialize(&AxiVdma, Config, Config->BaseAddress);
	if (Status != XST_SUCCESS) {
		xil_printf("VDMA Configuration Initialization FAILED\r\n");
		return XST_FAILURE;
	}

	Status = XAxiVdma_SetFrmStore(&AxiVdma, NUMBER_OF_WRITE_FRAMES,
								XAXIVDMA_WRITE);
	if (Status == XST_SUCCESS) {
		xil_printf("Frame store number configured SUCCESSFULLY\n\r");
		return XST_SUCCESS;
	}else if (Status == XST_NO_FEATURE){
		xil_printf ("VDMA FAIL. Access to Frame Store Register is not enabled\n\r");
		return XST_FAILURE;
	}else{
		return Status;
	}
}

 

Secondly, I configure VDMA Write channel. As you can see, the function XAxiVdma_FsyncSrcSelect() is called here and loaded with value "2" to select SOF on TUSER(0):

 

static int  VdmaWriteChSetup (XAxiVdma *InstancePtr)
{
	int Index;
	u32 Addr;
	int Status;

	WriteCfg.VertSizeInput = FRAME_VERTICAL_LEN;
	WriteCfg.HoriSizeInput = FRAME_HORIZONTAL_LEN;

	WriteCfg.Stride = FRAME_HORIZONTAL_LEN;
	WriteCfg.FrameDelay = 0;  /* This example does not test frame delay */

	WriteCfg.EnableCircularBuf = 1;
	WriteCfg.EnableSync = 0;  /* No Gen-Lock */

	WriteCfg.PointNum = 0;    /* No Gen-Lock */
	WriteCfg.EnableFrameCounter = 0; /* Endless transfers */

	WriteCfg.FixedFrameStoreAddr = 0; /* We are not doing parking */

	Status = XAxiVdma_FsyncSrcSelect(&AxiVdma, 2, XAXIVDMA_WRITE);
	if (Status != XST_SUCCESS){
		xil_printf ("Setting register to Enable SOF on TUSER signal FAILED\n\r");
	}else{
		xil_printf ("Register configuration to enable SOF on TUSER signal configured SUCCESSFULLY\n\r");
	}

	Status = XAxiVdma_DmaConfig(&AxiVdma, XAXIVDMA_WRITE, &WriteCfg);
	if (Status != XST_SUCCESS) {
		xil_printf("Write channel configuration FAILED %d\r\n", Status);
		return XST_FAILURE;
	}else{
		print ("VDMA Write Channel configuration OK\n\r");
	}

	Addr = START_FRAME_ADDRESS;
	WriteCfg.FrameStoreStartAddr [0]= Addr;

	Status = XAxiVdma_DmaSetBufferAddr(&AxiVdma, XAXIVDMA_WRITE,
									WriteCfg.FrameStoreStartAddr);
	if (Status != XST_SUCCESS) {
		xil_printf("VDMA Write channel set buffer address FAILED %d\r\n", Status);
		return XST_FAILURE;
	}else{
		print ("VDMA Read Channel Setting of buffer address OK\n\r");
	}



	return XST_SUCCESS;
}

Thirdly, I call the following function:

 

 

Status = XAxiVdma_DmaStart(&AxiVdma, XAXIVDMA_WRITE);
if (Status != XST_SUCCESS) {
xil_printf("Start Write transfer failed %d\r\n", Status);
return XST_FAILURE;
}

 

Lastly, I past all the #defines I use for VDMA parameters:

 

#define FRAME_VERTICAL_LEN 0xA
#define FRAME_HORIZONTAL_LEN 40// EXAMPLE FOR 10x10 pixels FRAME WITH 4 BYTES PER PIXEL

#define NUMBER_OF_READ_FRAMES 0
#define NUMBER_OF_WRITE_FRAMES 1
#define DELAY_TIMER_COUNTER 0 // We set this value to "0" becuase we dont want Interrupts caused by Delay.

 So..... my final questions are:

 

2. Is the process I follow, and all my configuration correct?? Do I have to modify some others registers to kickoff a VDMA transfer?? 

 

3. Is some kind of delay present since I activate signal SOF on my core, until VDMA is ready to process the data?? (I have read in these forums lot of VDMA problems looking for one similar to mine, and i have found one post with someone telling that VDMA puts TREADY low during 16 clock cycles after SOF is received on TUSER(0). Is this right??)

 

One of the tests I have done is to call XAxiVdma_IsBusy() before start the transfer and result is "0". Once I kick off transfer, I call repeatedly XAxiVdma_IsBusy () to check when the transfer finishes, but I only get "1" as the result of the function, so VDMA is busy, but I understand that it has understood my order of SOF from TUSER(0).

 

Any help is really appreciated, because I can not understand where the problem comes from. Probably I am missing something but I can not find out why. 

 

Again thanks for your support. 

 

Regards.

0 Kudos
12 Replies
Adventurer
Adventurer
4,723 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

I have checked control and status registers with function:  XAxiVdma_DmaRegisterDump(&AxiVdma, XAXIVDMA_WRITE).

 

The results are these:

 

Control Reg: 10043

Status Reg: 1C000

CDESC Reg: 0

TDESC Reg: 0

 

Checking bit values for these registers in VDMA documentation tell me the following:

 

· Bit 6 and Bit 5 of Control Register are well configured to work with external frame sync (SOF on TUSER(0)). So it seems the hw is ok in this part.

· Bit 15 of Status Register is HIGH. That indicates an End Of Line Late Error

· Bit 16 of Status Register is HIGH. That indicates an Interrupt on Error. I understand that this error is due to the one before (End of line late error). As I have not configured interrupts on my system, there is no handler configured for this.

 

As explained in my first mail, I work with a "fake frame generator" (VHDL core) which generates a frame of 10x10 pixels. Every pixel has 4 bytes. So from my point of view, the parameters I have loaded to registers with vertical and horizontal size are correct.

 

#define FRAME_VERTICAL_LEN        0xA  //  10 lines. 0xA in hexadecimal
#define FRAME_HORIZONTAL_LEN   0x28 // 40 bytes per line. 10 pixels with 4 bytes per line. 0x28 in hexadecimal. 

WriteCfg.VertSizeInput = FRAME_VERTICAL_LEN;
WriteCfg.HoriSizeInput = FRAME_HORIZONTAL_LEN;
WriteCfg.Stride = FRAME_HORIZONTAL_LEN;

So where can be the problem?? What other thing could generate this kind of error (EOL late) when vertical and horizontal parameters are correct??

 

Any clue is welcomed.

 

Many thanks. 

0 Kudos
Xilinx Employee
Xilinx Employee
4,698 Views
Registered: ‎08-02-2011

Re: VDMA not working as expected with SOF in TUSER(0)

Hello,

Don't use a 10x10 frame. Use something more realistic. I've run into this before with small frames where the small frame size would interrupt the burst length on the MM size.

If i recall correctly, the doc now says 64x64 minimum size (or maybe 32x32)
www.xilinx.com
0 Kudos
Adventurer
Adventurer
4,695 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Many thanks for your answer @bwiec

 

I have just tried with a 32x32 frame with 4 bytes per pixel but unfortunately without success. The error is the same. 

 

I have also found this AR on xilinx: https://www.xilinx.com/support/answers/54934.html  

 

I paste a screenshot of this one (In red where my problem appears. In yellow, the solution I have carried out (Enable data realignment engine and try with HSize and Stride multiples of TDATA_WIDTH).

 

AR54934.png

 

But at this moment, I am getting the same error. 

 

I am going to try with 128 x 128 pixels for example. 

 

I will keep you informed. 

 

Again many many thanks for your answer.

0 Kudos
Adventurer
Adventurer
4,687 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Hi again @bwiec. Nothing new.......

 

The same behaviour with a 128x128 pixels frame. The same error on status register.

 

Dump register before request a frame:

Dump register for channel 7E200030:

        Control Reg: 10043

        Status Reg: 10000

        CDESC Reg: 0

        TDESC Reg: 0

And Dump register after request a frame (VDMA always busy after request the frame):

Dump register for channel 7E200030:

        Control Reg: 10043

        Status Reg: 1C000

        CDESC Reg: 0

        TDESC Reg: 0

VSize and HSize parameters:

#define FRAME_VERTICAL_LEN     0x80  // 128 lines = 0x80
#define FRAME_HORIZONTAL_LEN   0x200 //128 pixels, 4 bytes each = 512 bytes = 0x200

Could it be caused by TKEEP signal or any other signal in AXI stream bus not taken into account by me ?? Once SOF is sent, Does VDMA put TREADY high, or is there some delay since SOF is received until VDMA asserts TREADY ?? I can tell you this because maybe the first pixels are lost while TREADY is not asserted by VDMA and this could be the reason why VDMA never reaches VSIZE value to finish transfer.

 

If you know, or think, in any other reason that could cause this problem, please, let me know. 

 

I will be investagting more in deep why this behavior. 

 

Thanks for your support. 

 

0 Kudos
Xilinx Employee
Xilinx Employee
4,677 Views
Registered: ‎08-02-2011

Re: VDMA not working as expected with SOF in TUSER(0)

Could it be caused by TKEEP signal or any other signal in AXI stream bus not taken into account by me ?? Once SOF is sent, Does VDMA put TREADY high, or is there some delay since SOF is received until VDMA asserts TREADY ?? Hmm okay. Yes, improper driving of TKEEP could cause an issue. It should probably be tied to all 1's in most cases (if it's gnd, it will error out). VDMA puts tready high when it's ready to accept data regardless of SOF. Whatever's driving it should only need to respect the AXI Stream spec and assert tvalid non-dependent on tready behavior. That said, SOF will cause things internal to the core to reset, flush line buffers, etc.
www.xilinx.com
0 Kudos
Adventurer
Adventurer
4,666 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Hi again. 

 

I have checked VDMA MPD and TKEEP signal is tied to VCC, so I understand that this is correct:

 

PORT s_axis_s2mm_tkeep = TKEEP, DIR = I, VEC = [(C_S_AXIS_S2MM_TDATA_WIDTH/8)-1:0], BUS = S_AXIS_S2MM, ENDIAN = LITTLE, INITIALVAL = VCC

As you can see in my first post, I follow the Axi stream protocol :

 

- SOF and TVALID activated on first pixel of the frame

- TVALID actitvated every time data is available to VDMA

- TLAST activated every last pixel of a line.

 

I am trying to change VDMA parameters in XPS to see if something is causing this behaviour (disable store & forward buffers, change line buffer depth,...)  but at this moment no success.

 

I dont know what more can I do. In addition I can not use DMA instead of VDMA beause of the maximum length allowed by DMA (8MB). One complete frame from my sensor is 8.5MB. I am completely stucked.....

 

Hope to find the problem with the VDMA . 

 

I will tell you and I will post the solution if I find it. 

 

thanks @bwiec.

 

0 Kudos
Adventurer
Adventurer
4,646 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Does anyone know how to make a dump of ALL registers of VDMA??

 

Because function XAxiVdma_DmaRegisterDump() only shows 4 registers (CR, SR, CDESC and TDESC).

 

Thanks by advance. 

0 Kudos
Adventurer
Adventurer
4,643 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Last tests I have done is to increase HSIZE value on Microblaze code to check if error dissapear, and to see if EOL early error is activated instead of EOL late error. 

 

Surprisingly the SOL late error has dissapeared, but there is no flag for EOL early error as expected. 

 

As I told you, the tests now are with a 128x128 pixels frame (4 bytes per pixel). HSIZE should be 512. With this value I had the SOL late error (bit 15 of status register). But If I increase HSIZE value to 1024 or 2048 (the two tests I have done) no error flag is asserted!!!!!!!!!!!!!!!!!!!!!!!!!!!. I would expect bit 8 of status register high (EOLEarlyErr) but no........

 

@bwiec, Have you ever faced with a similar problem??

 

I have read lot of information in the forum, but impossible to solve the problem..... Is there any known bug with ISE Design Suite 14.7 and VDMA?? 

0 Kudos
Adventurer
Adventurer
4,573 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Hello again. 

 

I continue without controlling VDMA. I have learnt to dump all registers from XMD console and I have found that register 0xAC (S2MM start address) is all zeros!!

 

I pass this information when I configure Write Channel (where VDMA_TX_BUFFER_BASE is my DDR3 MEM_BASE_ADDRESS =0xA8100000):

 

	WriteCfg.HoriSizeInput = FRAME_HORIZONTAL_LEN;

	WriteCfg.Stride = FRAME_HORIZONTAL_LEN;
	WriteCfg.FrameDelay = 0;  // This example does not test frame delay

	WriteCfg.EnableCircularBuf = 1; // 
	WriteCfg.EnableSync = 0;  // No Gen-Lock

	WriteCfg.PointNum = 0;    // No Gen-Lock
	WriteCfg.EnableFrameCounter = 0; // Endless transfers

	WriteCfg.FixedFrameStoreAddr = 0; // We are not doing parking  
	WriteCfg.VertSizeInput = FRAME_VERTICAL_LEN;

	Addr = VDMA_TX_BUFFER_BASE;
	WriteCfg.FrameStoreStartAddr[0]= Addr;

	Status = XAxiVdma_DmaSetBufferAddr(&AxiVdma, XAXIVDMA_WRITE,
									WriteCfg.FrameStoreStartAddr[0]);

Once kick off the transfer, while VDMA stands busy (stands busy all time after kick off the transfer), these are registers values. As you see no errors are indicated, the only one is that S2MM start address is all zeros. 

 

Please, if someone has an idea about the problem, even if you think is stupid, please, let me know because i am completely stucked.

 

thanks.

 

7E200000:   00000000
7E200004:   00000000
7E200008:   00000000
7E20000C:   00000000
7E200010:   00000000
7E200014:   00000000
7E200018:   00000000
7E20001C:   00000000
7E200020:   00000000
7E200024:   00000000
7E200028:   00000000
7E20002C:   504A0031
7E200030:   00010043
7E200034:   00010000
7E200038:   00000000
7E20003C:   00000000
7E200040:   00000000
7E200044:   00000000
7E200048:   00000001
7E20004C:   00000004
7E200050:   00000000
7E200054:   00000000
7E200058:   00000000
7E20005C:   00000000
7E200060:   00000000
7E200064:   00000000
7E200068:   00000000
7E20006C:   00000000
7E200070:   00000000
7E200074:   00000000
7E200078:   00000000
7E20007C:   00000000
7E200080:   00000000
7E200084:   00000000
7E200088:   00000000
7E20008C:   00000000
7E200090:   00000000
7E200094:   00000000
7E200098:   00000000
7E20009C:   00000000
7E2000A0:   00000080
7E2000A4:   00000200
7E2000A8:   00000200
7E2000AC:   00000000
7E2000B0:   00000000
7E2000B4:   00000000
7E2000B8:   00000000
7E2000BC:   00000000
7E2000C0:   00000000
7E2000C4:   00000000
7E2000C8:   00000000
7E2000CC:   00000000
7E2000D0:   00000000
7E2000D4:   00000000
7E2000D8:   00000000
7E2000DC:   00000000
7E2000E0:   00000000
7E2000E4:   00000000
7E2000E8:   00000000
7E2000EC:   00000000
7E2000F0:   00000000

 

0 Kudos
Xilinx Employee
Xilinx Employee
3,122 Views
Registered: ‎08-02-2011

Re: VDMA not working as expected with SOF in TUSER(0)

Hello,

Can you probe the Memory Mapped side with an ILA and post the activity?

To answer your question, there is no delay between tuser and when you can start sending data. As long as tready is high, the VDMA is ready to accept data.

Also, you say you're doing 128x128 now but the early screenshots show tlast asserting on pixel #99 which would be the wrong size.
www.xilinx.com
0 Kudos
Adventurer
Adventurer
2,979 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Hi @bwiec.

 

Sorry for my late reply. I didnt expect an answer for this topic.

 

I have partially solved the problem with the VDMA. I am getting the same error and it has been impossible for me to solve it, but i have realized that data is saved on DDR3 memory although VDMA indicates EOLLateErr ( I paste status register after frame request):

 

7E200034:   0001C000

What I have done is directly write to registers with XAxiVdma_WriteReg() function instead of using the functions related in VDMA example:

 

#define FRAME_HORIZONTAL_LEN 512  // For a 128x128 pixels frame, 4 bytes each pixel.
#define FRAME_VERTICAL_LEN 128

void VdmaRegisterConfig (void){ XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0x30, 0x4); //Reset Channel while (XAxiVdma_ResetNotDone(&AxiVdma, XAXIVDMA_WRITE)== 1){ } XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0x30, 0x43); // Select Fsync on TUSER(0) and Start VDMA XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0xAC, VDMA_TX_BUFFER_BASE); //Config Frame buffer address XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0xA4, FRAME_HORIZONTAL_LEN); //HSize configuration XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0xA8, FRAME_HORIZONTAL_LEN); //Stride Length XAxiVdma_WriteReg (XPAR_AXI_VDMA_0_BASEADDR, 0xA0, FRAME_VERTICAL_LEN); }

Writing directly to registers, Start Frame Address is correctly saved in S2MM_START_ADDRESS register, and data is passed to DDR3 memory. Every frame I take I have to call to the function above to reset VDMA and load again registers, but as it is impossible to make VDMA work correctly, this is the only way I can do it. 

But now, I am facing a new problem with cache coherence (at least I think this is the problem).

 

Now, the first frame is correctly saved on memory, but the second frame and the next ones are not correctly read from DDR memory. From second frame, when I try to read DDR data corresponding to the last frame saved the first 16 positions of memory contains data from previous frame (always the first 16 memory positions).

 

Before data is transferred from VDMA to DDR3 memory I use the following function to invalidate the cache:

 

microblaze_invalidate_dcache();

And before read data from memory i use the following function:

 

Xil_DCacheFlushRange((u32)VDMA_TX_BUFFER_BASE, (FRAME_VERTICAL_LEN*FRAME_HORIZONTAL_LEN))

So I would expect to have cache completely clean to send and receive data, but it seems that no.

 

So, Am i doing something wrong?? Why Am I getting data from previous frames when I try to read data from memory after cleaning cache??

 

Thanks by advance. 

 

Regards.

 

## Regarding to the problem with the VDMA, as I told you before in this post, I am using a custom core to interface with VDMA through AXI 4 stream.

 

I paste the code of the custom core for you to check (if possible) if something is wrong on it, and to confirm if this is the reason why VDMA always give SOF Late Error.

 

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;

------------------------------------------------------------------------------
-- Entity Section
------------------------------------------------------------------------------

entity vdma_stream_generator is
	port 
	(
		-- DO NOT EDIT BELOW THIS LINE ---------------------
		-- Bus protocol ports, do not add or delete. 
		ACLK	: in	std_logic;
		ARESETN	: in	std_logic;
		S_AXIS_TREADY	: out	std_logic;
		S_AXIS_TDATA	: in	std_logic_vector(31 downto 0);
		S_AXIS_TLAST	: in	std_logic;
		S_AXIS_TVALID	: in	std_logic;
		M_AXIS_TVALID	: out	std_logic;
		M_AXIS_TDATA	: out	std_logic_vector(31 downto 0);
		M_AXIS_TLAST	: out	std_logic;
		M_AXIS_TREADY	: in	std_logic;
		M_AXIS_TUSER   : out std_logic
		-- DO NOT EDIT ABOVE THIS LINE ---------------------
	);

attribute SIGIS : string; 
attribute SIGIS of ACLK : signal is "Clk"; 

end vdma_stream_generator;


architecture EXAMPLE of vdma_stream_generator is

	constant TOTAL_PACKETS : integer := 128;
	constant TOTAL_LINES : integer := 128;

   type STATE_TYPE is (Idle, Read_Inputs, Write_Outputs);

   signal state        : STATE_TYPE;

   -- Accumulator to hold sum of inputs read at any point in time
   signal sum          : std_logic_vector(31 downto 0);
	signal packets_counter : integer := 0;
	signal lines_number : integer := 0;
	
	signal flag_start : std_logic := '1';


begin

   -- S_AXIS_TREADY  <= '1'   when state = Read_Inputs   else '0';
   S_AXIS_TREADY  <= '0' when state = Write_Outputs else '1';
   M_AXIS_TVALID <= '1' when state = Write_Outputs else '0';
	M_AXIS_TUSER <= '1' when ((packets_counter = 1)and (flag_start = '1') and (state = write_outputs)) else '0';
	M_AXIS_TLAST <= '1' when ((packets_counter = total_packets) and (state = write_outputs)) else '0';
   M_AXIS_TDATA <= sum;

   The_SW_accelerator : process (ACLK) is
	
	variable lines_number : integer := 0;
	
   begin  -- process The_SW_accelerator
    if ACLK'event and ACLK = '1' then     -- Rising clock edge
      if ARESETN = '0' then               -- Synchronous reset (active low)
        -- CAUTION: make sure your reset polarity is consistent with the
        -- system reset polarity
        state        <= Idle;
        sum          <= (others => '0');
      else
        case state is
          when Idle =>
            if (S_AXIS_TVALID = '1') then
              state       <= Read_Inputs;
              sum         <= (others => '0');
            end if;

          when Read_Inputs =>
            if (S_AXIS_TVALID = '1') then
              -- Coprocessor function (Adding) happens here
              sum         <= S_AXIS_TDATA;
              if (S_AXIS_TLAST = '1') then
                state        <= Write_Outputs;
					 packets_counter <= packets_counter +1;
				  end if;
            end if;

          when Write_Outputs =>
            if (M_AXIS_TREADY = '1') then
                state <= Idle;
					 if (packets_counter = TOTAL_PACKETS) then
						packets_counter <= 0;
						lines_number := lines_number +1;
						if (lines_number = TOTAL_LINES) then	
							lines_number := 0;
							flag_start <= '1';
						end if;
					 elsif(flag_start = '1') then
						flag_start <= '0';
					 end if;
            end if;
        end case;
      end if;
    end if;
   end process The_SW_accelerator;
end architecture EXAMPLE;

 

 

 

 

0 Kudos
Adventurer
Adventurer
2,831 Views
Registered: ‎10-24-2016

Re: VDMA not working as expected with SOF in TUSER(0)

Only to close the post, finally, I have discarded the usage of the VDMA. As I related in my last post, i could make it "work" (data was present on DDR3 memory although VDMA present errors on status register). Well, this was good for a 128x128 frame. Once I have changed the frame size to real frame size, data is not saved on DDR3 memory. Same configuration, and all the same, except the size of the frame. The same errors was present on status register with real frame size but this time data was not saved on memory. 

 

So, the solution I have adopted to carry out the design ( I know it is far from to be the best solution) is to use 2 DMA. At the beginning I discarded DMA because of the maximum lenght of the packet allowed by HW in a single transfer (8MBytes. I require 8.5MB to save a complete frame). So I have used 2 DMA to save data on memory and I split the frame on the logic( half of data for each DMA).

 

Elegant: NO. Functional: YES.

 

Thanks @bwiec for your initial support. 

0 Kudos