Der oben beschriebene Fehler wird in der Simulation des Avalon® MM Slave BFM angezeigt, wenn die Latenzreaktion nicht korrekt eingestellt wurde.
Der Fehler wird ausgelöst, wenn der Avalon MM Master mehrere Burst-Lesetransaktionen an den Avalon MM Slave BFM ausgibt und der Slave BFM versucht, eine Lesereaktion zu steuern, bevor die Lesereaktion des vorherigen Bursts abgeschlossen ist.
Nachfolgend finden Sie eine Beispielsequenz, die den Zeitplankonflikt auslösen wird.
1. Fordern Sie einen Burst-Lesezugriff (Größe 2) mit einer Latenz von 4 an.
2. Fordern Sie beim nächsten Zyklus einen Burst-Lesezugriff (Größe 2) mit einer Latenz von 3 an.
Der Slave BFM zählt die Latenz in Bezug auf die Zeit, zu der er den Befehl empfängt. Er versucht, die dritte Lesereaktion zu steuern, bevor er die zweite Lesereaktion vorantreibt.
Diese Überlagerung von Antworten löst den Zeitplankonflikt aus.
Um diesen Fehler zu umgehen, verwenden Sie den set_response_latency-API-Aufruf, um den Zeitlichen der Lesereaktion zwischen Burst-Transaktionen anzupassen. Folgen Sie der folgenden Formel, um eine feste Antwortlatenz für alle Burst-Lesetransaktionen festzulegen:
Maximale Burst-Lesegröße = Smax,
Mindestzyklen zwischen Burst-Leseanfragen = Cmin.
Antwortlatenz = Smax - Cmin 1.
Im oben genannten Beispiel ist die maximale Burst-Lesegröße = 2 und die Mindestzyklen zwischen Burst-Leseanfragen = 1. Die Antwortlatenz für jede Burst-Leseanforderung sollte 2 sein.
Weitere Informationen finden Sie in set_response_latency Beschreibung im Benutzerhandbuch Avalon Verification IP Suite (https://www.altera.com/en_US/pdfs/literature/ug/ug_avalon_verification_ip.pdf#page=56).