Two Avalon ST Interfaces comparison

[Altera_Forum]

Hello all, 

 First, I'm sorry if this is not the right forum to post such question !  Second, I desperately need your help !  I'm trying to compare two avalon streaming interfaces (one output from a vip frame buffer and the other from a scaler) with the same resolution ! My problem is how to make my component receives both frames at the same time (make both startofpacket signals asserted at the same time) ? Logically the scaler source (or my custom component 1st sink) should control the other sink (from frame buffer) but I couldn't make that happen !   Any suggestion would be appreciated !  PS : Can I modify the alpha blending mixer behavior to make it compare the 2 sinks ? Or is there any explanation on how does it behave ?   Thank you

[Altera_Forum]

I don't know about the VIP components so I can't answer your PS question, but more generally if you want to compare two streams, you can use the ready signals on both your sinks to control the data traffic. If one of the streams is sending data before the other one, set its ready signal to 0 to block the stream, until you get the data from the other one. 

Please note that when doing something like that it is a good idea to have a buffer like a Avalon Stream FIFO if the source doesn't support back-pressure.

[Altera_Forum]

Hi Daixiwen, 

 Thank you for responding   Both sources support back-pressure and the Frame Buffer is a passive component so it delivers data whenever the READY signal is asserted (otherwise it stalls). So I'm using an SCFIFO for the scaler sources and I'm trying to read it when the READY signal from the output and the VALID signal from the frame buffer are asserted ! But I still get a delayed data ! Can I manage to control both sources without using a FIFO ?  Do you have any example on how to stall a stream to a startofpacket of another stream ?  thank you

[Altera_Forum]

You should be able to keep the ready signals on both sinks to '0' and wait until both valid signals are asserted. Then you can read both sources simultaneously.

[Altera_Forum]

So both sources won't deliver data until I assert the READY signal ? I thought that the data is delivered whenever the ready signal is '1' and not the opposite ! 

 thank you

[Altera_Forum]

The data is transferred from the source to the sink when both the ready and the valid signals are '1'. The ready signal is controlled by the sink and the valid signal is controlled by the source, so that way both the sink and the source can control the data flow.

[Altera_Forum]

Still doesn't explain how to align both frames ! My idea is to deliver data from the SCALER output and whenever there is valid data I set the READY signal for the other sink to '1'  

First sink ==> scfifo ==> output  --> here I assert the READY signal for the second sink if first_sink.valid = '1'  I couldn't align both frames with this ! can you suggest another technique ?  thank you

[Altera_Forum]

Could you show with a timing diagram the problem you are having aligning frames? As far as I know, what I described in# 4 (put BOTH ready signals to 0 and only put them to 1 when BOTH valid signals are 1) should work.

[Altera_Forum]

Just to be clear: Altera VIP Frame Buffer component will buffer entire frames, ping-pong, then output. So, you are looking at at least (1) frame quantum of delay between input and output side of Frame Buffer. 

 Other than that, it should really be as simple as Daixiwen has already described.

[Altera_Forum]

hi again  

 @Ted : I know that there is at least 1 frame delay between the VIP FB input and output (I'm counting on that since I'm gonna compute the difference between an old and the current frame) and I spend a lot of time reading the vip user guide and the avalon spec so I'm pretty sure that what Daixiwen described should work. but it doesn't and it's driving me crazy ! I appreciate your help and I'm desperately in need of a solution   @Daixiwen : I attached the signal tap screen shot : the two counters count the number of pixel delivered (first counter from the FB source | second counter from the fifo that receives the scaler output)  I hope that would help you figure out my mistake   PS : the used resolution is 800x600 so maximum count is 480000  thank you a lot

[Altera_Forum]

The only comment I have on the capture you just posted is that FRAME_COUNTER|CLR is not tracking EOP like NEW_COUNTER|CLR is.

[Altera_Forum]

that's because the FRAME_COUNTER|CLR is mapped to AST_OLD_EOP and the NEW_COUNTER|CLR to the output_EOP (or q(31)) ! As I said each counter count the delivered pixels from a source (FRAME_COUNTER <= frame buffer output| NEW_COUNTER <= scaler output)

[Altera_Forum]

I'm a bit confused about what your signal names mean... which ones are your inputs and which ones are your outputs? Which signals are you controlling? Why is the FRAME_COUNTER increasing when there doesn't seem to be any data coming on FRAME_FIFO?

[Altera_Forum]

Hello Daixiwen, 

 I'm sorry if the attachment is not clear enough ! Here is a brief description about the arch I used :  The NEW frame called AST_NEW_* is tied to an SCFIFO (named NEW_FIFO) as follow : AST_NEW_READY <= NOT (NEW_FIFO_FULL) AST_NEW_VALID => NEW_FIFO_WRITE AST_NEW_SOP & AST_NEW_DATA & AST_NEW_EOP => NEW_FIFO_DATA  The OLD Frame (named AST_OLD_*) is not tied to a fifo (in previous arch it was) but it's controlled by the output source (named AST_DIFF_*) as follow :  AST_OLD_READY <= AST_DIFF_READY and NOT (NEW_FIFO_EMPTY) AST_OLD VALID => NEW_FIFO_READ  I attached an image that describe the arch I used   For the counters : The NEW_COUNTER counts the data output from the NEW_FIFO so it uses the NEW_Q signals  The FRAME_COUNTER counts the data coming from the AST_OLD sink so it uses AST_OLD_EOP (as CLR) and AST_OLD_VALID (as ENABLE)   Hope this clarifies things   Thank you

[Altera_Forum]

There could be a problem with your fifo_read signal. You only tie it to VALID from AST_OLD, which means that it could be 1 even if there is no data in the FIFO. fifo_read (and AST_DIFF_VALID) should be AST_OLD_VALID AND not_empty. Other than that, you may end up in a cycle delay between the two streams. 

I think it would be easier if you got rid of the FIFO, and use a ready made "Avalon-ST Single Clock FIFO" on the AST_NEW interface in QSYS/SOPC Builder. That way your custom component doesn't have to control a FIFO and just has two sinks and one source, with direct cabling. It should be easier to get the synchronization right.

[Altera_Forum]

Hello 

 I thought that I could manage that using the AST_OLD_READY signal (AST_OLD_READY <= AST_DIFF_READY AND NOT_EMPTY) !!  So you recommend using a direct cabling ( wait for both valid to be asserted without setting the READY signal to '1' then receive data from each source pixel by pixel) ? it sounds too easy but I'm not sure how to make this !  THANK YOU

[Altera_Forum]

Yes this will limit the flow on the OLD interface and prevent it from coming in if the FIFO is empty. But if this is happening, you still have an asserted valid signal on your AST_DIFF interface, even if no data is coming, so your output stream will be weird. Second, if you do it this way you need to be sure that the FIFO is protected against a read operation when empty. It is a parameter that can be adjusted in the megawizard. Without the protection you can have garbage results from the FIFO if the fifo_read signal is asserted while it is empty. 

 But yes, it would be a lot easier to remove the FIFO. As I said, just add a "Avalon ST single clock FIFO" in QSYS/SOPC Builder, and in your component you'll just have to handle the ready and valid signals.

[Altera_Forum]

You make it sound so easy !  

I'm a bit confused myself ! what's the difference between instantiating the FIFO inside my component and outside it ? If I use the second technique ! What should I use as a reference sink ? the one output from the scaler I guess (because that's the PAL video source) ? The delay between the two frames can be half frame (not counting the first buffered frame) ! How can I eliminate that using just ready and valid signals ?  I really appreciate your help   Thank You

[Altera_Forum]

I think it is a lot simpler because you don't have to write any code to control the FIFO. You just have two avalon sinks (OLD and NEW) and one avalon source (DIFF). 

What do you mean by "reference sink"? As I see it the two sinks have the same role in your component, you just wait for both of them to provide data before going on. As for the delay, it shouldn't be a problem as long as the FIFO that you add before your component is big enough to hold all the data.

[Altera_Forum]

Ok thank you Daixiwen I will try to make my component work as you described and I will come back to you (if you don't mind) to tell the results ! 

 Thank you for your help

[Altera_Forum]

Hello again, 

 Sorry for coming back so soon but I need to ask you guys two things :  1- For the NEW sink the data is coming from a PAL camera with pixel rate of 27 MHz but for the second (OLD) sink the data is delivered from a frame buffer with the pixel rate of 130 MHz (System Clock) ! I think that would make a problem if I use the technique you suggested ?  2- The frame rate is also different because for the frame buffer frame dropping/repeating is enabled (frame rate conversion) ! This would make getting data from both sinks a lot more complicated right ?  Thank you