fix build-doc

This commit is contained in:
Ciro Santilli 六四事件 法轮功
2020-09-02 02:00:01 +00:00
parent 58e82a5b91
commit 059a7ef9d9

View File

@@ -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 <<moesi-cache-coherence-protocol,state: M>> 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 <<moesi,state: M>> 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 <<moesi-cache-coherence-protocol,from M to O>>! <<cache-coherence>> is being maintained!
and from this we see that this read request from CPU2 made a cache from CPU1 go <<moesi,from M to O>>! <<cache-coherence>> 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 <<cache-coherence>>, we know that this is one of the ways that cache coherence may be maintained in MOESI-like protocols.