Article ID: 000076147 Content Type: Troubleshooting Last Reviewed: 12/31/2014

RapidIO II IP Core Maintenance Master Port Does Not Deassert Write Request Signal After waitrequest Signal is Deasserted

Environment

    Quartus® II Subscription Edition
BUILT IN - ARTICLE INTRO SECOND COMPONENT

Critical Issue

Description

The RapidIO II IP core’s Maintenance master port is supposed to implement the Avalon-MM interface master protocol. However, the IP core does not implement this protocol correctly. Specifically, the usr_mnt_read and usr_mnt_write output signals do not comply with the specification if the usr_mnt_waitrequest input signal is already asserted at the time the IP core initially asserts the usr_mnt_read or usr_mnt_write output signal. In this case, the IP core does not deassert this signal even after the usr_mnt_waitrequest input signal is deasserted.

According to the Avalon-MM protocol specification, the master must hold the request signal (usr_mnt_read or usr_mnt_write) asserted until after the slave deasserts the usr_mnt_waitrequest signal, and then deassert the request after the read request is communicated or the write transaction is completed. However, with the current IP core implementation, the IP core maintains the request asserted even after the completion of the request. In this case the IP core never deasserts the request signal (usr_mnt_read or usr_mnt_write). As a result, the Avalon-MM slave will erroneously assume that the IP core is making additional, new requests.

For more information about the Avalon-MM specification, refer to Avalon Interface Specifications.

Resolution

This issue has no workaround.

This issue is fixed in version 14.1 of the RapidIO II IP core.

Related Products

This article applies to 1 products

Intel® Programmable Devices

1