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