Warum tritt Nios® II Prozessorsystemsperre auf, wenn ich auf die generische Tri-State-Controller-IP zugreife und das Waitrequest-Signal aktiviert ist?

Die folgende Liste listet die Abfolge von Ereignissen auf, aus deren Grund die Systemsperre Nios® II Prozessorsystems beim Zugriff auf die IP des generischen Tri-State-Controllers mit aktiviertem Waitrequest-Signal angezeigt wird:

1. Wenn das Waitrequest-Signal aktiviert ist, muss die Lese-Wartezeit/Schreib-Wartezeit/Setup-Zeit/Daten-Hold-Zeit auf Null gesetzt sein. Die Aktivierung des Waitrequest-Signals mit einem Nicht-Null-Wert für die Wartezeit, Einrichtung und Haltezeit ist eine illegale Parameterisierung.
2. Aufgrund einer Einschränkung im System validiert der Platform Designer diese illegale Einstellung jedoch nicht und fordert einen Fehler auf, um den Benutzer zu verwarnen.
3. Aufgrund der illegalen Einstellungen wird eine interne Komponente im Controller falsch parameterisiert, was dazu führt, dass die IP das Lese-/Schreib-Anforderungssignal abgibt. Die IP wird die Anfrage an den Pin Sharer nur geltend machen, wenn das Waitrequest-Signal hoch ist.

Um diesen Fehler zu vermeiden, stellen Sie in der IP-GUI des generischen Tri-State-Controllers sicher, dass die Lese-Wartezeit/Schreib-Wartezeit/Setup-Zeit/Daten-Haltezeit in der Registerkarte Signal Timing auf Null gesetzt ist, wenn waitrequest Signal in der Registerkarte Signalauswahl aktiviert ist.

.

Alternativ können Sie auch, wenn die oben genannten Einstellungen nicht erfüllt sind, die Systemsperre vermeiden, indem Sie waitrequest während Leerlaufzuständen/ohne Transaktionen hoch halten. Eine hohe Wartezeit während Leerlaufzyklen ermöglicht es, die Anfrage auf den Pin-Sharer zu setzen und den normalen Betrieb fortzusetzen. Dies wird jedoch nicht empfohlen, es sei denn, Sie können die oben angegebene Problemumgehung nicht befolgen.