Searched hist:11650 (Results 1 - 4 of 4) sorted by relevance
| /gem5/src/cpu/o3/ | ||
| H A D | decode_impl.hh | 11650:fe601d7bd955 Thu Sep 22 05:49:00 EDT 2016 Rekai Gonzalez-Alberquilla <rekai.gonzalezalberquilla@arm.com> cpu: Fix the O3 CPU Drain The drain did not wait until stages were ready again. Therefore, as a result of messages in the TimeBuffer being drain, the state after the drain was not consistent and asserts fired in some places when the draining happened after a stage got blocked, but before the notification arrived to the previous stages. Change-Id: Ib50b3b40b7f745b62c1eba2931dec76860824c71 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> |
| H A D | rename_impl.hh | 11650:fe601d7bd955 Thu Sep 22 05:49:00 EDT 2016 Rekai Gonzalez-Alberquilla <rekai.gonzalezalberquilla@arm.com> cpu: Fix the O3 CPU Drain The drain did not wait until stages were ready again. Therefore, as a result of messages in the TimeBuffer being drain, the state after the drain was not consistent and asserts fired in some places when the draining happened after a stage got blocked, but before the notification arrived to the previous stages. Change-Id: Ib50b3b40b7f745b62c1eba2931dec76860824c71 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> |
| H A D | iew_impl.hh | 11650:fe601d7bd955 Thu Sep 22 05:49:00 EDT 2016 Rekai Gonzalez-Alberquilla <rekai.gonzalezalberquilla@arm.com> cpu: Fix the O3 CPU Drain The drain did not wait until stages were ready again. Therefore, as a result of messages in the TimeBuffer being drain, the state after the drain was not consistent and asserts fired in some places when the draining happened after a stage got blocked, but before the notification arrived to the previous stages. Change-Id: Ib50b3b40b7f745b62c1eba2931dec76860824c71 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> |
| H A D | fetch_impl.hh | 11650:fe601d7bd955 Thu Sep 22 05:49:00 EDT 2016 Rekai Gonzalez-Alberquilla <rekai.gonzalezalberquilla@arm.com> cpu: Fix the O3 CPU Drain The drain did not wait until stages were ready again. Therefore, as a result of messages in the TimeBuffer being drain, the state after the drain was not consistent and asserts fired in some places when the draining happened after a stage got blocked, but before the notification arrived to the previous stages. Change-Id: Ib50b3b40b7f745b62c1eba2931dec76860824c71 Reviewed-by: Andreas Sandberg <andreas.sandberg@arm.com> |
Completed in 111 milliseconds