Re: SCE-MI Routed Example

Jason and ITC commitee,

Sorry to swerve on this but I just realized that I have
more up to date versions of Routed that have already fixed
these bugs.

I would like to instead propose that we superceed the existing
examples and the corrections I just sent at with the contents
of the two attached files.

I was just now able to just verify that these work and, in
fact these are what we've been using for some time.

Brian, please ignore my previous e-mail and superceed with this one.

For the Destination transactor code in A.2.3.4 on electronic page 81
of draft 1.0.6 please just replace the entire transactor
with that attached in Destination.v.

For the ClockAdvancer transactor code in A.2.3.5 on electronic page 82
of draft 1.0.6 please just replace the entire transactor
with that attached in ClockAdvancer.v.

Also, please try to be sure that indentation is properly replicated
in the courier FrameMaker text (including comments).

-- johnS

Stickley, John wrote:

> 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
> ________________________________________________________________
>

-- 
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
________________________________________________________________