[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fw: why Target cannot change its mind



 
----- Original Message -----
From: Weng
To: pci-sig@znyx.com
Sent: Friday, April 13, 2001 7:40 PM
Subject: why Target cannot change its mind

Hi Brian,
I disagree with your claim:
" I think the harm is in the complexity of logic needed in the master to
support TRDY changing state when the master is inserting a wait state."

First of all, I emphasize the following assertion:
"In other words, when Either Master or Target is inserting wait cycles, NOT
FOR LAST DATA (FRAME# = '0'), the opposite partner can change its state
(IRDY# or TRDY#) without any harm if no accompanying STOP# change !!! That's
all."
My above assertion is more relax than PCI specs at least in paper. In designing implementation, it would be much easier to design.
 
I don't want to challenge the specs, nor to violate it in my design. I am just curious of trying to know why PCI specify a tougher limit on
both Master and Target on data transfer.
 
I cannot imagine what damage will happen when one side says wait a minute, another side says, hay, if you want a wait, I want it too, let make a deal 1 clock or 2 later.
 
Weng Tianxiang
 
wtx@umem.com
wengtianxiang@yahoo.com
 
Micro Memory Inc.
9540 Vassar Avenue
Chartsworth, CA 91311
Tel: 818-998-0070
Fax: 818-998-4459




----- Original Message -----
From: Brian Small <small@quicklogic.com>
To: <wtx@umem.com>; <pci-sig@znyx.com>
Sent: Friday, April 13, 2001 2:55 PM
Subject: RE: Why cannot Target change its mind


> Weng,
>
> I think the harm is in the complexity of logic needed in the master to
> support TRDY changing state when the master is inserting a wait state.
>
> In any case, it certainly would break a great deal of PCI masters if
targets
> began to behave in this way.  This is because all previous masters were
> designed to the current spec, which assumes that once TRDY is low, TRDY
will
> stay low until the master completes the data cycle by making IRDY low.
>
> - Brian Small
>
> -----Original Message-----
> From: Weng [mailto:wtx@umem.com]
> Sent: Friday, April 13, 2001 2:34 PM
> To: pci-sig@znyx.com
> Subject: Re: Why cannot Target change its mind
>
>
>
> Hi,
> I disagree with your following opinions:
> 1. "Anyway, such behaviour by the target might lead to bus cycles wastage
> or,
> for example, let the master (some kind of bridge for example) prefetch
> data and throw them away..."
> 2. "In my opinion you misread the specs here. The assertion of IRDY# must
> also be considered as a commitment for a data phase by the master as seen
by
> the target. In this situation, catastroph may happen if the master wants
> to read to non-prefetchable and then changes its mind, since the target
> may have read the data (with side effect) and then will not be able to
> deliver it to the master."
>
> I don't see any harm will happen: if FRAME# = '0' and IRDY# changes while
> TRDY# = '1' and insists FRAME# = '0'. It only change clock time on which
> clock to transfer data, not whether or not the data will be transfered.
>
> And I don't see any harm will happen if FRAME# = '0' and IRDY# = '1' and
> TRDY# changes its state
>
> In other words, when Either Master or Target is inserting wait cycles, NOT
> FOR LAST DATA (FRAME# = '0'), the opposite partner can change its state
> (IRDY# or TRDY#) without any harm!!! That's all.
>
> When entering last data cycle, FRAME# = '1' and IRDY# = '0', there is no
> room for either Master or Target to change mind.
>
> Weng Tianxiang
>
> wtx@umem.com
> wengtianxiang@yahoo.com
>
> Micro Memory Inc.
> 9540 Vassar Avenue
> Chartsworth, CA 91311
> Tel: 818-998-0070
> Fax: 818-998-4459
>
> ----- Original Message -----
> From: Gérard Roudier <groudier@club-internet.fr>
> To: Weng <wtx@umem.com>
> Cc: <pci-sig@znyx.com>
> Sent: Friday, April 13, 2001 10:42 AM
> Subject: Re: Why cannot Target change its mind
>
>
>
>
> On Fri, 13 Apr 2001, Weng wrote:
>
> > Hi,
> > PCI 2.2 p.53: Once a target has asserted TRDY# or STOP#, it cannot
change
> DEVSEL#, TRDY#, or STOP# until the current data phase completes.
> >
> >  I have two questions about the above definition.
> >
> > The reason that DEVSEL# and STOP# cannot be changed is clear, I don't
see
> any merit why TRDY# cannot be changed if Target found Master is asserting
> wait cycles and it wants to change mind too.
> >
> > 1. On what senerio the changing TRDY# signal will have permanent damage
to
> any transactions?
>
> I imagine that this allows the other part (the master) to anticipate the
> data phase, if such anticipation can optimize the data transfer, and avoid
> side effects without too much complexity.
> Anyway, such behaviour by the target might lead to bus cycles wastage or,
> for example, let the master (some kind of bridge for example) prefetch
> data and throw them away...
>
> > When I have been designing Master module, I don't see any difference in
> design whether or not PCI-Target is changing its mind. The only logic that
> go into my design is IRDY# = '0' and (TRDY# = '0' or STOP# = '0'), that
> means only when both Master and Target agree with a transaction, the deal
is
> made, otherwise wait until the above conditions happen.
> >
> > 2. While not allowing Target to change its mind, why there is no
> symmetrical limit on Master side, that is, on IRDY#?
>
> In my opinion you misread the specs here. The assertion of IRDY# must also
> be considered as a commitment for a data phase by the master as seen by
> the target. In this situation, catastroph may happen if the master wants
> to read to non-prefetchable and then changes its mind, since the target
> may have read the data (with side effect) and then will not be able to
> deliver it to the master.
>
> > My opinion is: (a relaxed condition that is good enough to match
original
> definition)
> > Once a target has asserted DEVSEL# or STOP#, it must be asserted until a
> transaction is finished. Data is transfered only on conditions that IRDY#
=
> '0' and TRDY# = '0'. Target can change TRDY# state if no data is
transfered.
>
> You should forget about such suggestion, in my opinion.
>
> > Weng Tianxiang
> >
> > wtx@umem.com
> > wengtianxiang@yahoo.com
> >
> > Micro Memory Inc.
> > 9540 Vassar Avenue
> > Chartsworth, CA 91311
> > Tel: 818-998-0070
> > Fax: 818-998-4459
>
>   Gérard.
>
>