scaler usage in run time control

The runtime control register map for the scaler is given on page A-19 of the user guide. The general description of avalon slave interfaces is given on page 4-14.

1 - Which scaling algorithm are you using?

2 - Are you using SoPC builder are interfacing directly to the core?

3 -

--- Quote Start ---

and input width and height as 32x32 using the control packet but the problem is the core is not discarding the extra data if i gave more than 1024 pixels and the output is same size as the input

--- Quote End ---

This concerns me, why do you have "extra data". The length of the video packet should match exactly what's specified in the control packet. Where is the "extra data" coming from? Who is creating the control packets?

The biggest problem I've seen so far that people have had with the VIP suite is not that the cores aren't working but that they misunderstand how the entire video system must be architected.

Jake

I am using nearest neighbour now and i am not using SOPC.I am using my own logic.

I am controlling the control packets and just gave the extra packets to check if the error recovery is working or not .I am giving the exact number of packets of video data normaly but the problems i mentioned are in that case only.

Can I ask what you saw or read that made you assume the scaler would simply discard any data that existed beyond the length specified in the control packet? I would be surprised if that were the case. The control packet is simply to inform the scaler of how many pixels are in each line, and how many lines there are. Using this information it can determine things like:

- Which phase to use given a certain scaling ratio.

- When to begin reading in the next line vs. continuing to operate on a currently buffered line.

Maybe if you give the "endofpacket" signal with the 1024th pixel, the following extra pixels will be ignored. I guess I'm thinking if we lie to the scaler, we can't expect it to behave in any certain way.

Jake

--- Quote Start ---

Can I ask what you saw or read that made you assume the scaler would simply discard any data that existed beyond the length specified in the control packet? I would be surprised if that were the case. The control packet is simply to inform the scaler of how many pixels are in each line, and how many lines there are. Using this information it can determine things like:

- Which phase to use given a certain scaling ratio.

- When to begin reading in the next line vs. continuing to operate on a currently buffered line.

Maybe if you give the "endofpacket" signal with the 1024th pixel, the following extra pixels will be ignored. I guess I'm thinking if we lie to the scaler, we can't expect it to behave in any certain way.

Jake

--- Quote End ---

I saw the error recovery section of the used guide and understood the extra data discarding behaviour.At last i could able to solve the scaler runtime controlling problem. But still some issues are there regarding the algorithm and my kit.

I had no problem using the nearest neithbour,bilinear , bicubic and polyphase upto 12 taps and 16 phases but with 12 taps and 16 phased the error led on my cyclone 3 development kit is glowing and i could not get the output.

Do u have any idea regarding the phase and tap selections and their effects regarding my problem.

Do u have used the deinterlacer megacore with motion adaptive algorithm,since i had some doubts regarding it.can u help me in clearing them.

I have used the deinterlacer in motion adaptive mode. What are your questions?

Jake

In my project i want to develop video system which can support upto 1920x1080 resolution and I am not using sopc builder.

I want to use the deinterlacer function with 10bit input of 3 colour planed in parallel.I am using ddr2sdram for frame buffering.

1.can u help me regarding the datawidth of ddr2sdram required.Avalon interface usage.

2.I want to use ddr2 high performance memory controller.so how can i interface my 30bit din_data to the ddr2 controller in input

3.can u help me in selecting the avalon master parameters in megawizard for efficient implementation .

4.It would be great help if u had any detailed deinterlacer function application interfacing document

regards

Ysc

I can run the memory bandwidth calculations for you.

1 - How wide physically is your ddr2 memory?

2 - Are you running 1080p or just 1080i?

3 - It would help if you gave me a description of your entire video processing path (what blocks you have and in what order).

Jake

1.ddr2 16 bit wide

2.output resolution is 1080p

3.There two paths one for sdi and another for cvbs,component,dvi,vga

the paths will have Deinterlacer,CSC,scaler in second path and CRS and Gamma corrector if required in another path.

According to my calculations:

You did not mention the color space you are working in. I'm going to assume 4:4:4 YCbCr. Your 16 bit wide DDR2 has a bandwidth of 10.656 Gbps if operated at 333MHz (666 data rate). Obviously the calculations change if you run it slower or faster than this. This gives you a local interface width of 64 bits using the Altera high performance controller.

Here are the calculations for the MA deinterlacer.

1 - Converting 4:4:4 1080i60 to 4:4:4 1080p60 - MA deinterlacer bandwidth is ~11.281Gbps (106% of your available bandwidth). Not enough bandwidth

2 - Converting 4:4:4 1080i60 to 4:4:4 1080p30 - MA deinterlacer bandwidth is ~7.299Gbps (68% of your available bandwidth).

The above calculations are valid for either 10bit 4:4:4 YCbCr or 10bit RGB.

In 9.1, Altera is supposed to release the 4:2:2 version of the deinterlacer. So if you are doing YCbCr and you can process it in 4:2:2

1 - Converting 1080i60 to 1080p60 results in a bandwidth of ~8Gbps or ~75% of your available bandwidth.

Jake

Hi jake

Thanks for ur reply.

Can u help me in best avalon parameter selection and how to interface the ddr2 high performance controller with the deinterlacer.

Regards

ysc