Re: SCE-MI Routed Example

Jason,

Your ClockAdvancer fix looks fine.

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 // }

---------------------------------------------------

Here is the proposed text change for the ClockAdvancer
transactor code in A.2.3.5 on electronic page 82 of
draft 1.0.6:

             if (receiveReadyOut == 1)
                 transmitReadyOut <= 0;
             if( readyForCclock && cclockEnabled ) begin
                 if (cycleCount == 1) begin
                     transmitReadyOut <= 1;
                     readyForCclock <= 0;
                 end
                 cycleCount <= cycleCount - 1;
             end
         end // }
     end // }
endmodule // }

-- johnS
<eom>

Jason Rothfuss wrote:

> Hi John,
>
> I'm attaching two files, Destination.v and ClockAdvancer.v. These are
> the versions that I have been using. Let me know if they look ok to you.
>
> To summarize the changes:
>
> ClockAdvancer:
> ==============
> - Moved the if statement where outTransmitReady is assigned '0' above
> the if statment when outTransmitReady is assigned '1', otherwise
> deadlock can occur if outReceiveReady is '1' from time 0.
>
> 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.
>
> Thanks,
> Jason
>
>
> -----Original Message-----
> From: Stickley, John [mailto:john_stickley@mentorg.com]
> Sent: Mon 10/25/2004 1:33 PM
> To: Jason Rothfuss
> Subject: Re: SCE-MI Routed Example
>
> Jason,
>
> 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.
>
> As for the second issue with the ClockAdvancer transactor:
>
> Looks like you're right here as well.
>
> How about changing the last if as follows:
>
> if( receiveReadyOut == 1 && trasmitReadyOut == 1 )
> transmitReadyOut <= 0;
>
> If these changes look good or you have recommended alternatives,
> I can raise these issues at the committee and we can get them
> corrected in the spec.
>
> Thanks for pointing these out.
>
> -- johnS
>
> Jason Rothfuss wrote:
>
> > Hi John,
> >
> > I'm writing because I have some questions about the Routed example in
> > the SCE-MI spec dated May 29,2003.
> >
> > [Destination Transactor]
> > - 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.
> >
> > [ClockAdvancer Transactor]
> > - Next issue is related to the transmitReadyOut signaling for the
> > ClockAdvancer:
> > - It would seem that if receiveReadyOut is asserted, transmitReadyOut
> > will always be deasserted. This results in deadlock, as data can
> > never be tranferred to the OutPort while receiveReadyOut is asserted.
> >
> > I'd like to know your thoughts on these two issues, and see if there
> > is something that I might be missing.
> >
> > Best Regards,
> > Jason
> >
> > --
> > Jason Rothfuss rothfuss@verisity.com
> > Verisity Design (310) 210-2754 cell
> >
> >
> >
>
> --
>
> This email may contain material that is confidential, privileged
> and/or attorney work product for the sole use of the intended
> recipient. Any review, reliance or distribution by others or
> forwarding without express permission /\
> is strictly prohibited. If you are /\ | \
> not the intended recipient please | \ / |
> contact the sender and delete / \ \
> all copies. /\_/ K2 \_ \_
> ______________________________/\/ \ \
> John Stickley \ \ \
> Principal Engineer \ \________________
> Mentor Graphics - MED \_
> 17 E. Cedar Place \ john_stickley@mentor.com
> Ramsey, NJ 07446 \ Phone: (201) 818-2585
> ________________________________________________________________
>

-- 
This email may contain material that is confidential, privileged
and/or attorney work product for the sole use of the intended
recipient.  Any review, reliance or distribution by others or
forwarding without express permission        /\
is strictly prohibited. If you are     /\   |  \
not the intended recipient please     |  \ /   |
contact the sender and delete        /    \     \
all copies.                      /\_/  K2  \_    \_
______________________________/\/            \     \
John Stickley                   \             \     \
Principal Engineer               \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________