RapidIO II IP Core Maintenance Master Port deassert Schreibanforderungssignal nicht, nachdem das Waitrequest-Signal deasserted wurde

Der Wartungs-Master-Port des RapidIO II IP-Kerns wird angenommen zur Implementierung des Avalon-MM-Schnittstellen-Masterprotokolls. Allerdings: IP-Core implementiert dieses Protokoll nicht korrekt. Speziell die und usr_mnt_write die usr_mnt_read Ausgabe Signale entsprechen nicht der Spezifikation, wenn die usr_mnt_waitrequest Eingabe Das Signal wird zum Zeitpunkt, den der IP-Kern anfänglich geltend macht, bereits bestätigt die usr_mnt_read oder usr_mnt_write die Ausgabe Signal. In diesem Fall wird dieses Signal vom IP-Kern nicht deassert. selbst nachdem das usr_mnt_waitrequest Eingangssignal wurde nicht mehr hinzugefügt.

Gemäß den Avalon-MM-Protokollspezifikationen ist der Master muss das Anforderungssignal (usr_mnt_read oder usr_mnt_write) halten. bis nach der Deassertierung des Signals durch den usr_mnt_waitrequest Slave eingefügt wurde, und die Anfrage nach der Mitteilung der Leseanforderung erneut zusammengesetzt werden oder die Schreibtransaktion abgeschlossen ist. Allerdings mit dem Aktuellen IP-Core-Implementierung, der IP-Kern hält die Anfrage aufrecht, die bestätigt wird auch nach Abschluss der Anfrage. In diesem Fall der IP-Kern deassert niemals das Anforderungssignal (usr_mnt_read oder usr_mnt_write). In der Folge nimmt der Avalon-MM-Slave fälschlicherweise an, dass der DER IP-Kern stellt zusätzliche, neue Anfragen.

Weitere Informationen zur Avalon-MM-Spezifikation finden Sie unter zur Avalon Schnittstellenspezifikationen.

Dieses Problem hat keine Problemumgehung.

Dieses Problem wurde in Version 14.1 des RapidIO II IP-Kerns behoben.