From aede4c24fc8edda7396f757d3fd6476d26b47d2b Mon Sep 17 00:00:00 2001 From: lkcl Date: Tue, 23 Jun 2020 10:56:28 +0100 Subject: [PATCH] --- 3d_gpu/architecture/6600scoreboard/discussion.mdwn | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/3d_gpu/architecture/6600scoreboard/discussion.mdwn b/3d_gpu/architecture/6600scoreboard/discussion.mdwn index 2a09464bf..8f30616eb 100644 --- a/3d_gpu/architecture/6600scoreboard/discussion.mdwn +++ b/3d_gpu/architecture/6600scoreboard/discussion.mdwn @@ -105,8 +105,11 @@ however the important part is to understand and appreciate - *at all* negotiation* procedure that is *required* to have *two separate phases*: -* an "offer" phase and -* a "completion" phase. +* an "offer" phase, being the start of the transaction. +* an "exchange" phase, during which the "offer" may not change. +* a recognition of "completion" being the end of the transaction. + +thus we have actually 2 distinct phases (offer, exchange) delineated by terminology that marks the time at which the FSM transitions (offer, exchange, complete). this is absolutely fundamental to understand when it comes to our architecture. proposals to use technology and APIs that are of the @@ -135,8 +138,6 @@ we will therefore need to design a Bus Protocol that does actually work for this processor, based on the standard Contract of Sale to help guide us in that design. -l. - # Scoreboard and LDST Questions -- 2.30.2