Re: SCE-MI Routed Example

Jason,

Great. Glad we're in agreement.

BTW, this Destination transactor is what we've often termed in
some of our SCE-MI meetings as a "well behaved" transactor
with regard to clock control and ops on output ports.

A well behaved output transactor should always stop the
clock if it sees that an output port is not ready to take
its data immediately. This promotes deterministic behavior.

Thanks for bringing up these issues. It was very helpful.
And do let us know if you come across more.

-- johnS

Jason Rothfuss wrote:

> Hi John,
>
> Ok, I see now. I think that I had a problem with the CclockEnable
> signaling, which is what caused the data to stay on TokenIn for more
> than 1 cycle.
>
> Thanks,
> Jason
>
>
> -----Original Message-----
> From: Stickley, John [mailto:john_stickley@mentorg.com]
> Sent: Wed 11/3/2004 5:22 PM
> To: Jason Rothfuss
> Subject: Re: SCE-MI Routed Example
>
> Jason,
>
> The idea is that the token from the DUT is valid for exactly
> 1 clock before it goes invalid.
>
> The Destination transactor assumes in can move the data
> to the SCE-MI output port in the same cycle it is valid. If it
> learns otherwise (i.e. receiveReady low) it will immediately stop
> the clock thus freezing the DUT in time and forcing it to hold the
> data as long as is necessary. In otherwords, as long as the DUT
> is not clocked, the data from it will not be overwritten by
> other data.
>
> This is why it works without latching.
>
> -- johnS
>
> Jason Rothfuss wrote:
>
> > Hi John,
> >
> > The reason for latching the TokenIn data is to prevent stale data on the
> > bus from being re-transmitted to the SceMiMessageOutPort. If data that
> > has already been sent to the SceMiMesageOutPort stays on the bus for
> > some time, the same data can be repeated (ie. log shows that DaffyDuck
> > arrives in Cupertino 20 times). The key here is that there was no logic
> > to indicate that the data has already moved, since transmitReady is only
> > based on a non-zero destID and cclockEnabled.
> >
> > Per the spec, transmitReady should indicate to the SceMiMessageOutPort
> > that it has valid data to be transmitted. Since there is no handshaking
> > with the sender of TokenIn, there is no way to "clear" the TokenIn
> > data. If receiveReady doesn't go low (implementation could provide a
> > buffer), transmitReady could falsely indicate that it has valid data
> > resulting in multiple transmissions of the same token.
> >
> > Regards,
> > Jason
> >
> > -----Original Message-----
> > From: Stickley, John [mailto:john_stickley@mentorg.com]
> > Sent: Wed 11/3/2004 4:13 PM
> > To: Jason Rothfuss; itc@eda.org
> > Subject: 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
> > ________________________________________________________________
> >
>
> --
>
> 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
________________________________________________________________