cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
987 Views
Registered: ‎10-12-2018

AXI VDMA Line Size Limitation

Jump to solution

Hello everybody,

I am working on a project that the input image has around 15,000 RGBC pixels per line each by 12bits which means around 90KBytes per line. Based on Xilinx AXI VDMA product guide (PG020), the length of the corresponding register for setting the horizontal size in bytes is limited to 16bits. That means the maximum length could be around 65KBytes per line that is too far from my desired length. 

May I know if I am calculating right? or maybe not?

If it is a limitation of VDMA IP core, may I know if there are any other solutions to handle the stated application? I would be really grateful if you could give me any suggestion.

Thank you very much in advance. Looking forward to hearing from you.

 

Kindest Regards,

Amir

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
927 Views
Registered: ‎10-04-2017

Hi @amir.massah,

 

You are correct. The HSIZE register is 16bits wide

 2018-12-04 08_05_19-Xilinx Documentation Navigator 2017.2 -  http___www.xilinx.com_support_documenta.png

RGBC looks like it may have equivalent formatting to RGBA we do have a Frame Buffer which can be used to store into memory. However, this does not support RGBA12, it supports RGBA8. See PG278 for more information.

2018-12-04 08_10_56-Xilinx Documentation Navigator 2017.2 -  http___www.xilinx.com_support_documenta.png

-Sam

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub

View solution in original post

0 Kudos
4 Replies
Highlighted
Moderator
Moderator
952 Views
Registered: ‎10-04-2017

Hi @amir.massah,

 

I am not familiar with RGBC. A quick google search shows this as Bayer, please correct me if I am wrong. In Bayer, each component is considered a pixel. 

This would mean that your calculation is 12bits per component x 15000 components per line   / 8bits = 22500 bytes per line.

 

Usually, Bayer is not stored, it is common for Bayer to be converted to another before storing the data. (I do not think that our IP is setup for RGBC)

 

** also we provide a Frame Buffer which may suit your needs as well. Please see the product page.

 

-Sam

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub
0 Kudos
Highlighted
Adventurer
Adventurer
940 Views
Registered: ‎10-12-2018

Hi @samk,

 

Thank you for your reply. 

Actually, there are 4 data each by 12 bits per pixel that means 4x12=48 bits per pixel, and we have 15,000 pixels per line so we will have 15,000 x 48 / 8 = 90,000 Bytes per line.

But, my question is that in any case the VDMA is limited to line size of maximum 2^16 = 65,536 Bytes per line, right?

 

Kindest Regards,

Amir

0 Kudos
Highlighted
Moderator
Moderator
928 Views
Registered: ‎10-04-2017

Hi @amir.massah,

 

You are correct. The HSIZE register is 16bits wide

 2018-12-04 08_05_19-Xilinx Documentation Navigator 2017.2 -  http___www.xilinx.com_support_documenta.png

RGBC looks like it may have equivalent formatting to RGBA we do have a Frame Buffer which can be used to store into memory. However, this does not support RGBA12, it supports RGBA8. See PG278 for more information.

2018-12-04 08_10_56-Xilinx Documentation Navigator 2017.2 -  http___www.xilinx.com_support_documenta.png

-Sam

 

 

Don't forget to reply, kudo, and accept as solution.

Xilinx Video Design Hub

View solution in original post

0 Kudos
Highlighted
Explorer
Explorer
902 Views
Registered: ‎07-18-2011

@amir.massah,

Since you have 4 groups of 12 bits per pixel, and 15,000 pixels per line, can you split your data into 2 paths, each with 24 bits per pixel, and use two VDMAs to write your data into memory?  Each VDMA would require 3 bytes * 15,000 pixels, or 45,000 bytes, which would be addressable with 16 bits. 

Alternately, you could write two VDMAs, alternating 48-bit pixels between the two VDMAs at 7500 pixels per line, which would accomplish the same thing.

It would also require two VDMAs out the output side to read the data, and some custom IP to synchronize them and piece the data back together, but that would be fairly simple, you just have to synchronize to the tuser bits at the start of the frame on each path.