From 059a7ef9d9c378a6d1d327ae97d90b78183680b2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Wed, 2 Sep 2020 02:00:01 +0000 Subject: [PATCH] fix build-doc --- README.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.adoc b/README.adoc index a978e4a..4dee5a3 100644 --- a/README.adoc +++ b/README.adoc @@ -16814,7 +16814,7 @@ Things get a bit interleaved with CPU1, but soon afterwards we see the CPU2 make 471202000: Event: system.cpu2.dcache.mem_side-MemSidePort.wrapped_function_event: EventFunctionWrapped 140 scheduled @ 471203000 .... -Before the request moves on, some CPU1 action happens: a CPU1 is sending its data out! It hit the cache, and now we confirm that the cache is in <> as expected, since CPU1 had already been previously writting repeatedly to that address: +Before the request moves on, some CPU1 action happens: a CPU1 is sending its data out! It hit the cache, and now we confirm that the cache is in <> as expected, since CPU1 had already been previously writting repeatedly to that address: .... 471202000: Event: Event_87: Timing CPU icache tick 87 executed @ 471202000 @@ -16868,7 +16868,7 @@ The XBar receives the request, and notices that CPU1 cares about it, because obv 471203000: CoherentXBar: system.membus: recvTimingReq: Not forwarding ReadSharedReq [2040:207f] D=40cfe14bb15500005b323036383a323036665d20443d63383739333334626231353530303030206e756d3d32363630373300000000016d6973730a0000000000 num=266076 .... -and from this we see that this read request from CPU2 made a cache from CPU1 go <>! <> is being maintained! +and from this we see that this read request from CPU2 made a cache from CPU1 go <>! <> is being maintained! Furthermore, it also suggests that now CPU1 is going to supply the response to CPU2 directly from its cache, and the memory request will be suppressed! As mentioned in lecture notes from <>, we know that this is one of the ways that cache coherence may be maintained in MOESI-like protocols.