module Destination ( //inputs outputs //-------------------------- ---------------------------- // DUT port interface TokenIn ); input [31:0] TokenIn; // { wire [3:0] destID; reg readyForCclock; reg outTransmitReady; reg [31:0] outMessage; assign destID = TokenIn[7:4]; SceMiClockControl sceMiClockControl( //Inputs Outputs //---------------------------- ---------------------------- .Uclock(uclock), .Ureset(ureset), .ReadyForCclock(readyForCclock), .CclockEnabled(cclockEnabled), .ReadyForCclockNegEdge(1'b1), .CclockNegEdgeEnabled() ); SceMiMessageOutPort #32 sceMiMessageOutPort( //Inputs Outputs //---------------------------- ---------------------------- .TransmitReady(outTransmitReady), .ReceiveReady(outReceiveReady), .Message(outMessage) ); always@( posedge uclock ) begin // { if( ureset == 1 ) begin readyForCclock <= 1; outMessage <= 0; outTransmitReady <= 0; end else begin // { // if( DUT clock has been disabled ) // It means that this destination transactor is waiting to // unload its pending token and does not want to re-enable the // DUT until that token has been offloaded or else it may // loose arriving tokens in subsequent DUT clocks. if( readyForCclock == 0 ) begin // When the SceMiMessageOutPort finally signals acceptance // of the token, we can re-enable the DUT clock. if( outReceiveReady ) begin readyForCclock <= 1; outTransmitReady <= 0; end end else if( cclockEnabled && destID != 0 ) begin outMessage <= TokenIn; outTransmitReady <= 1; // if( token arrives but portal is not ready ) // Stop the assembly line ! (a.k.a. disable the DUT) if( outReceiveReady == 0 ) readyForCclock <= 0; end else if( outTransmitReady == 1 && outReceiveReady == 1 ) outTransmitReady <= 0; end // } end // } endmodule // } As for your Destination transactor fix, I don't think the extra latching logic is necessary. TokenIn values of 0 always signal idle, invalid data. TokenIn values on non-0 indicate valid data. I don't see a reason to have the extra latching logic. However, as for the issue you raised, I think the same fix you suggested for the clock advancer can apply here. That's what I'm going to recommend as you'll see below. -- johnS ITC Team, As per issues raised by Jason Rothfuss here are proposed changes to the Routed example in Annex A. I will forward additional changes to Routed as per IM 27 in a separate e-mail. --------------------------------------------------- Here is the proposed text change for the Destination transactor code in A.2.3.4 on electronic page 81 of draft 1.0.6: if (receiveReady == 1) transmitReady <= 0; if( readyForCclock == 0 ) begin // When the MessageOutPort portal finally signals acceptance // of the token, we can re-enable the DUT clock. if( receiveReady ) readyForCclock <= 1; end else if( cclockEnabled && destID != 0 ) begin message <= TokenIn; transmitReady <= 1; // if( token arrives but portal is not ready ) // Stop the assembly line ! (a.k.a. disable the DUT) if( receiveReady == 0 ) readyForCclock <= 0; end end // } end // } endmodule // } --------------------------------------------------- Thanks for the e-mail and the alert about these issues. On the Destination transactor, it looks like you're right for the case where receiveReady stays asserted when the transactor is ready to transmit. It works fine if receiveReady is not asserted right way and the transactor shifts into a state of disabling the clock. But if receiveReady is asserted at the time transmitReady is, it will generate 2 data movement cycles. I think the right way to fix this is to tack the following else if at the end: else if( transmitReady == 1 && receiveReady == 1 ) transmitReady <= 0; Tell me if you agree. Destination: ============ - Wait until a change is detected on TokenIn. This will indicate that we have new valid data. Based on the nature of this example, we will not have two identical tokens that are valid back-to-back. I believe that there is a functional error in the Destination > transactor listed in Appendix A (A.2.3.4) pp.68-69: > - If readyForCclock is asserted and cclockEnabled is asserted and > destID is non-zero, transmitReady will assert on the next cycle. > transmitReady will not deassert until the cycle following > when readyForCclock deasserts. > - This results in tranferring the same data to the OutPort multiple > times if receiveReady remains asserted. //=========================================================================== // Destination.v johns 10-2-00 // // The Destination transactor accepts tokens arriving from a point-of-exit // on the RouteMap and passes them to the SceMiMessageOutPort. // // Because we don't want to lose potentialy successive tokens arriving // from the RouteMap to this destination portal, we deassert // readyForCclock in the event that a token comes in but the // message output port is not able to take it because of tokens // simultaneously arriving at other destination portals. This way, we // guarantee that the entire RouteMap is disabled until all tokens are // offloaded from the requesting destination transactors. // // JAR: Jason Rothfuss //=========================================================================== module Destination ( //inputs outputs //-------------------------- ---------------------------- // DUT port interface TokenIn ); input [31:0] TokenIn; // { wire [3:0] destID; reg readyForCclock; reg outTransmitReady; reg [31:0] outMessage; wire oTr; wire [31:0] oMsg; reg [31:0] TokenIn_z1; // JAR: register the token so that we prevent // JAR: multiply sending tokens to the output // JAR: port. assign destID = TokenIn[7:4]; initial TokenIn_z1 = 32'b0; SceMiClockControl sceMiClockControl( //Inputs Outputs //---------------------------- ---------------------------- .Uclock(uclock), .Ureset(ureset), .ReadyForCclock(readyForCclock), .CclockEnabled(cclockEnabled), .ReadyForCclockNegEdge(1'b1), .CclockNegEdgeEnabled() ); SceMiMessageOutPort #32 sceMiMessageOutPort( //Inputs Outputs //---------------------------- ---------------------------- .TransmitReady(outTransmitReady), .ReceiveReady(outReceiveReady), .Message(outMessage) ); //------------------------------------------------------------------- // Re-write of the main always block. // outTransmitReady would remain asserted even if the OutPort // had accepted the data, thus repeatedly transmitting the same // data to the SW side. // // JAR //------------------------------------------------------------------- assign oMsg = (TokenIn_z1 != TokenIn & |TokenIn[7:4]) ? TokenIn : 32'b0; assign oTr = |oMsg[7:4] ? 1'b1 : 1'b0; always @(posedge uclock) begin:JAR if (ureset) begin outMessage <= 32'b0; TokenIn_z1 <= 32'b0; outTransmitReady <= 1'b0; end else begin TokenIn_z1 <= TokenIn; //---------------------------------------------------------------- // Wait for the token value to change. This is our indication // that valid data has arrived. // // JAR //---------------------------------------------------------------- if ((TokenIn_z1 != TokenIn) & |TokenIn[7:4]) begin outMessage <= TokenIn; outTransmitReady <= 1'b1; end else if (outReceiveReady & outTransmitReady ) begin // Token has been accepted outMessage <= 32'b0; outTransmitReady <= 1'b0; end end end // block: JAR always@( posedge uclock ) begin // { if( ureset == 1 ) begin readyForCclock <= 1; //outMessage <= 0; //outTransmitReady <= 0; end else begin // { // if( DUT clock has been disabled ) // It means that this destination transactor is waiting to // unload its pending token and does not want to re-enable the // DUT until that token has been offloaded or else it may // loose arriving tokens in subsequent DUT clocks. if( readyForCclock == 0 ) begin // When the SceMiMessageOutPort finally signals acceptance // of the token, we can re-enable the DUT clock. if( outReceiveReady ) begin readyForCclock <= 1; //outTransmitReady <= 0; end end else if( cclockEnabled && destID != 0) begin //outMessage <= TokenIn; //outTransmitReady <= 1; // if( token arrives but portal is not ready ) // Stop the assembly line ! (a.k.a. disable the DUT) if( outReceiveReady == 0 ) readyForCclock <= 0; end end // } end // } endmodule // }