Avalon MM Clock Crossing Bridge - Handshake not an option?

[bhunt]

Hi there, I'm using the Avalon MM clock crossing bridge, which implements the pipelined read transfer with variable latency. https://www.intel.com/content/www/us/en/docs/programmable/683091/20-1/pipelined-read-transfer-with-variable.html I have to interface to a custom avalon slave which does not support the pipelined read feature. So, I am trying to convince QSYS to output the bridge using the Handshake option, which should prevent the pipelined read activity. However, even if I change the qsys parameter from FIFO to Handshake, the core still allows pipelined reads, in simulation and implemented logic. Is this handshake actually implemented? It doesn't seem so. Using Quartus Prime 18.1 right now. Thanks, Bhunt

[KennyTan_Altera]

Kindly note that there will be some slowness on the first reply due to the public holiday, we will get back to you as soon as possible.

[ShengN_Intel]

Hi,

Check this document https://www.intel.com/content/www/us/en/docs/programmable/683609/23-1/faq.html (page 207):

The clock crossing bridge contains a pair of clock crossing FIFOs, which isolate the host and agent interfaces in separate, asynchronous clock domains. When you use a FIFO clock crossing bridge for the clock domain crossing, you add data buffering. Buffering allows pipelined read hosts to post multiple reads to the bridge, even if the agents downstream from the bridge do not support pipelined transfers.

Thanks,

Best Regards,

Sheng

[bhunt · Accepted solution]

That may be true if your Avalon interconnect is entirely within a QSYS subsystem. However, this is apparently not the case when the IP core is used stand-alone: in QSYS export all the ports of the IP, generate, and then instance the resulting IP as a module in your custom HDL. The simulation and implementation appear to work *only* in the pipelined read with variable latency mode, when used outside of the QSYS ecosystem. I have verified this in signaltap as well as in simulation.