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

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.

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

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.

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

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.

Two Avalon ST Interfaces comparison | Altera Community

21 Replies

Altera_Forum
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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
Honored Contributor
12 years ago
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

Forum Discussion

Two Avalon ST Interfaces comparison

21 Replies

Recent Discussions

Agilex 7 slew rate reconfiguration

Agilex-7 AXI MCDMA for PCIe hang

Constraints not being picked for DCFIFO

Can't generate F-Tile Ethernet Hard IP Design Example

MAX10 TSE reference design