about the use of avalon streaming interface

[Altera_Forum]

Hi Everybody, 

 In SOPC builder, I have a Clocked Video Input and Clocked Video Output. Then I have added a custom component in between the input and output.   and there is a pattern generator connected to the Clock Video Input, outside of SOPC builder (which works fine).  I have created a conduit interface, in order to see the avalon signals coming from the Clock Video Input to my custom component.  After compilation, I do a simulation, but nothing is happening, that is to say that there is no activity in the avalon streaming interface between the Clock video input and my component... I have set "ready" high in my component, but "valid", "startofpacket", "endofpacket" remain low from Clock Video Input...  When I delete the Clocked Video Input and use the Test pattern generator in SOPC builder, there is activity on the avalon streaming interface... between the Test pattern generator and my component.  Does someone know why my avalon streaming interface doesn't work with Clocked Video Input and works fine with Test pattern generator? Why don't  Clocked video input send received data through avalon?  Thanks you in advance, Francois

[Altera_Forum]

Really it sounds to me like in your simulation you've got something not quite right.  

 Are you sure the video into the clocked video input is active?  Are you sure you've asserted the locked signal? Are you sure the timing of your external video generator is correct. The clocked video input will discard it if it cannot find some consistency. Did you create the clocked video input with an avalon control port? If so you've got to write to the control port before the clocked video input will start outputting video.  Jake

[Altera_Forum]

Thanks for your answer 

 Yes, my pattern generator is active (800x600@60Hz) and the timing is correct, I have already used it for others projects where it is connected to the Clocked video input, so I know it works well. And I have checked again. Yes, the locked signal is asserted. And no, I don't use the avalon control port.  Here are some printscreen of the project: You can see that there is nothing on "valid1", "startofpacket1", "endofpacket1" (signals coming from the Clocked video input), "ready1" is set high.  Any other idea? I am suspicious about the clock input for the SOPC builder (here at 200Mhz). What is it used for? It clocks the avalon streaming sink, isn't it? (I have tried to put at the same frequency as the pixel clock frequency, but it still don't work) ...  Thanks,  Francois

[Altera_Forum]

Are you meeting timing requirements? Also, I didn't see vs going low in the screenshot. I assume it is though? 

 Jake

[Altera_Forum]

Timing is correct, the resolution for the test is (800 x 600) at 60 Hz, so the period for VS is 16.6 ms, out of the range of the simulation

[Altera_Forum]

1 - I realize it is your own IP but are you sure vs and hs should be inverted? 

2 - Do you have access to a good simulator. I would run a quick modelsim. 3 - Are you willing to send me your design?  Jake

[Altera_Forum]

1. Yes, VS and HS should be inverted: 

 From video and image processing suite user guide.pdf: Table 5–13: Clocked Video Input Signals for Separate Sync Format Video: vid_datavalid: When asserted the video is in an active picture period (not horizontal or vertical blanking). vid_h_sync / vid_v_sync: When 1, the video is in a horizontal /vertical sync period.  My panel is active low for HS and VS, that's why they are inverted.  2. I don't use modelsim  Thanks

[Altera_Forum]

If someone is interested by the solution of my problem: 

   The simulation was not long enough. The clocked video input block will start to transfer the data into next stage from the second frame. It seems to be the behavior of such block, I am consulting the designer now for the reason of this. But the good things is that it just drop the first frame.

[Altera_Forum]

Ah you hadn't mentioned this. Yes, the clocked video input block needs at least one complete frame of data before it knows what to insert into the video control packet that precedes the video packet. 

 Jake