Frame buffer IP

In SOPC Builder, i want to connect the dout of the "clocked video input" to 2 din of two "frame buffers"

Kindly confirm if it is applicable or not

I have a similar situation in which I just want to use a simple SOPC Builder design to frame sync 4:2:2 YCbCr (720p) video in the un-referenced 74.25MHz clk domain... to black burst sync'd 74.25MHz clock domain by using the Clocked Video Input -> Frame Buffer (with DDR2 intf.) -> Clocked Video Output

But even though I uncheck the "video in and out use the same clock" option on the CVI and CVO general parameters options I still get an error message from SOPC builder (Quartus II v10.0) if I try to use a different dout-to-din (or din-to-dout) on the interface between the Frame Buffer and the Clocked Video blocks.

So then what is the purpose of the "video in and out use the same clock" parameter? What is the simplest way to solve my problem of differing frame rate read and/or write using the Video and Image Processing Suite blocks?

Thank you for your reply.

If i use the "Clocked video input" instead of the "Clocked video output", how can we connect the dout of the "clocked video input" to 2 din of two "frame buffers"

Thank you for your co-operation. I use the frame reader in my design with the following settings:

Bits per pixel per color plane: 8

Number of color planes in parallel: 3

Number of color planes in sequence: 1

Maximum Image width: 1920

Maximum Image height: 1080

Master port width: 64

Read master FIFO depth: 1024

Read master FIFO burst target: 64

Use separate clock for the Avalon MM master interface: unchecked

Kindly confirm if the following calculations for number the words and the Single Cycle Color Patterns are true or not

1- // Words

IOWR(FRAMEREADER_BASE, 5, 259200); // (1920*1080*8)/64 = 259200

2- // Single Cycle Color Patterns

IOWR(FRAMEREADER_BASE, 6, 2073600); // 1920*1080=2073600 number of pixels in the frame multiplied by the number of single cycles required to represent one pixel

I use the frame reader in my design with the following settings:

Bits per pixel per color plane: 8

Number of color planes in parallel: 3

Number of color planes in sequence: 1

Maximum Image width: 1920

Maximum Image height: 1080

Master port width: 64

Read master FIFO depth: 1024

Read master FIFO burst target: 64

Use separate clock for the Avalon MM master interface: unchecked

Kindly confirm if the following calculations for number the words and the Single Cycle Color Patterns are true or not

1- // Words

IOWR(FRAMEREADER_BASE, 5, 259200); // (1920*1080*8*3)/48= 1036800

2- // Single Cycle Color Patterns

IOWR(FRAMEREADER_BASE, 6, 2073600); // 1920*1080=2073600 number of pixels in the frame multiplied by the number of single cycles required to represent one pixel

--- Quote Start ---

We use 2 frame buffer IPs in our design.

1- The first frame buffer: takes its data (din) from DVI Input IP (VGA_IN_INST) and writes this data into an SDRAM through the SDRAM controller. We do not use the read & dout of this Frame buffer . So, these unused interfaces are connected to an empty dummy component (reference to the service request no. 10773449 )

2- The second frame buffer: should read the data written by the first Frame buffer in the used SDRAM and gives this data to the DVI out IP (VGA_out_INST). W e do not use the write & din of this Frame buffer. So; these unused interfaces are connected to the same dummy component.

Taking into consideration that, the dummy component interfaces are Avalon.

Kindly advise about the following

1- Is it applicable to use a Frame buffer to write data in SDRAM and another Frame buffer to read this data from the same SDRAM as described above?

2- How to make sure that the second frame buffer reads the data from the same addresses used by the first frame buffer for writing in the SDRAM? This question is because the addresses are nit indicated when we instantiated the frame buffer in SOPC builder

--- Quote End ---

hi:

are you still focus on studing the transmitting video signals though ethernet to pc? I have just realizing sdram data transmitted to TSE_MAC by SGDMA to PC, now,I want to save the video data to SDRAM ,now I refer the demo :VIP and want to make it as a start project ,but I find the software is complex... so ,I hope to communicate with you.my email is young_zyj@163.com.

thanks

--- Quote Start ---

You can use an Avalon-ST Splitter Core to achieve that.

--- Quote End ---

hi,

In my SOPC design, I tryed connecting the Deinterlacer "dout" stream source to the Splitter's stream sink, but I get an error message saying: "The sink has a empty signal of 1 bits, but the source does not." So it looks like that since the Splitter core uses the "empty" signal the connecting cores also need to provide the "empty" signal.

Why aren't these cores setup so that they can be connected in SOPC and then ready to go? Must I provide an additional stage before the Splitter sink input and after it's source output inorder to provide the "empty" signal ?

--- Quote Start ---

hi,

In my SOPC design, I tryed connecting the Deinterlacer "dout" stream source to the Splitter's stream sink, but I get an error message saying: "The sink has a empty signal of 1 bits, but the source does not." So it looks like that since the Splitter core uses the "empty" signal the connecting cores also need to provide the "empty" signal.

Why aren't these cores setup so that they can be connected in SOPC and then ready to go? Must I provide an additional stage before the Splitter sink input and after it's source output inorder to provide the "empty" signal ?

--- Quote End ---

I'm not an expert in SOPC nor ST designs, as I had developed my own streaming interconnection, which I rather call dataflow interconnection, before looking into Altera's solution. However I looked up the ST- pin connections:

--- Quote Start ---

empty : Width 0–8 : Direction Source → Sink : Optional : Indicates the number of symbols that are empty during cycles that contain the end of a packet. The empty signal is not used on interfaces where there is one symbol per beat. If endofpacket is not asserted, this signal is not interpreted.

--- Quote End ---

It looks to me that you have instantiated the de-interlacer with a 0 width for the empty signal, and so you must instantiate the splitter wit a 0-width empty signal as well.