Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Altera_Forum
Honored Contributor I
748 Views

Qsys Interconnect - force usage of "response" signal

Hi, 

 

the Avalon IP Specification refers to the response[1:0] signal as an optional signal. However there is complete silence in the rest of the document how to activate it. In my case I am using a clock-crossing bridge to interface a custom Avalon slave (with the Avalon-MM interface towards my slave exported). The option "use response" is not present in the GUI and the signal is not present in the interface. 

 

Has anyone successfully activated the usage of this signal? How can this be done? 

 

Thanks!
0 Kudos
3 Replies
Altera_Forum
Honored Contributor I
30 Views

I suspect the bridges do not support response signalling yet so if you put one between a master and slave the response information will get dropped when it hits the bridge. If you were creating your own IP core you would add that signal in component editor just like the other signals like address, writedata, etc...

Altera_Forum
Honored Contributor I
30 Views

Made an SR to Altera and got the information the "response FIFO depth" has nothing to do with the response bus signal (completely undocumented IP parameter, name misleading, bad documentation on this one). The clock crossing bridge is not using the "response" signal at all. 

 

Too bad, it would have been a good way to inform the Avalon master in one access cycle that a requested transaction was actually aborted and not successful.
Altera_Forum
Honored Contributor I
30 Views

That's correct, the response depth dictates how many downstream reads can be in flight. The reason why it's called the response FIFO depth is being read data is technically a response to a read commands. 

 

If you need clock crossing in your system if you rely on Qsys to insert clock crossing adapters in the system then the response information will propagate. I know there are plenty of reasons to use the clock crossing bridge instead of relying on Qsys but I think that's the only valid workaround aside from creating a new clock crossing bridge that supports response signaling.