Forum Discussion
Honored ContributorTwo Avalon ST Interfaces comparison
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 you21 Replies
Altera_Forumthat'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
