[Fwd: RE: SCE-MI Routed Example]

ITC,

As promised here's the e-mail trail of the problems with the
Routed example found by Jason Rothfuss.

I'm checking over his fixes and drafting recommended re-wording
for the spec right now. I'll forward that shortly.

-- johnS

-------- Original Message --------
Subject: RE: SCE-MI Routed Example
Date: Fri, 29 Oct 2004 13:53:17 -0800
From: Jason Rothfuss <Jason.Rothfuss@verisity.com>
To: Stickley, John <john_stickley@mentor.com>
CC: Jason Andrews <jason@verisity.com>

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
________________________________________________________________