When the latency response has not been correctly set, the above error will be seen in the simulation of the Avalon® MM Slave BFM.
The error is triggered when the Avalon® MM Master issues multiple burst read transactions to the Avalon® MM Slave BFM, and the slave BFM is trying to drive a read response before the previous burst's read response is completed.
Below is an example sequence that will trigger the schedule conflict.
1. Request a burst read (size of 2) with a latency of 4.
2. On the next cycle, request a burst read (size of 2) with a latency of 3.
The slave BFM counts the latency with respect to the time that it receives the command, and it is trying to drive the third read response before driving the second read response.
This overlapping of responses triggers the schedule conflict.
To work around this error, use the set_response_latency API call to adjust the timing of the read response between burst transactions. Follow the formula below to set a fixed response latency for all burst read transactions:
Maximum burst read size = Smax,
minimum cycles between burst read requests = Cmin.
Response latency = Smax - Cmin 1.
The example above shows the maximum burst read size = 2, and the minimum cycles between burst read requests = 1. The response latency for each burst read request should be 2.
Please refer to the set_response_latency description in the Avalon® Verification IP Suite User Guide for more information.