[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why Target cannot change its mind
Hi,
I have to say that I have never backed out from my original view:
"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."
This assertion will never cause "deadlock" if 16 cycle limit for first data
cycle and 8 cycle limit are still effective.
Until so far among responses I received, there is no solid technology ground
indicating that my above assertion will cause any trouble except violation
of PCI specs.
My assertion is only a note that I never want it to be part of PCI
specification, and just wanted to note that THIS PART OF PCI SPECS IS
STRICTER THAN NECESSARY.
I would like to see any responses that say PCI specs is a necessary
condition, otherwise it will cause real trouble.
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: Joseph W Schulingkamp <jschulingkamp@agere.com>
To: <wtx@umem.com>
Sent: Monday, April 16, 2001 11:12 AM
Subject: Re: why Target cannot change its mind
Weng,
I'm a bit confused. When I referred to the "deadlock" situation, I was
referring to
the article you quoted from Srikiran Dravida below. Basically, if one
device
can
insert wait states as a response to another's wait state response, this can
continue
indefinitely without data transfer.
And the article about needing extra time to process data was the one from me
that you replied to this morning. Unfortunately, I haven't kept the text of
the
article, but
to summarize, a device can insert wait states to extend the amount of time
the
data is presented on the bus. This is because once a device asserts it's
"ready" (IRDY#
or TRDY#), it must commit to a transfer and if it's also driving data it
must
maintain
that data on the bus. The receiving device then has extra clock cycles to
process the
data (to calcuate parity or whatever) and when it's done handling the data,
it
can signal
the cycle to complete.
Hope this helps,
Joe
Weng wrote:
> Hi Joseph,
> Could you transfer me the "deadlock" situation article and your text on
> needing extra time to process the data.
>
> Thank you.
>
> Weng
>
> ----- Original Message -----
> From: Joseph W Schulingkamp <jschulingkamp@agere.com>
> To: <pci-sig@znyx.com>
> Sent: Monday, April 16, 2001 9:57 AM
> Subject: Re: why Target cannot change its mind
>
> No - I think the master and target both have the same kind if restriction.
> The master is committed once it asserts IRDY# and the target is committed
> once it asserts TRDY#.
>
> Srikiran is correct in describing a "deadlock" situation. The PCI spec
> avoids
> this by requiring the above commitments.
>
> For another scenario where this commitment is necessary, see my other
> response elsewhere in this thread (talking about devices needing extra
time
> to
> process the data, as in a parity checking system).
>
> Joe
>
> Richard Yuan wrote:
>
> > Hi Weng,
> >
> > I think this answer is right, but it still does not fully answer your
> question. This problematic scenario can be avoided by forcing the master
to
> commit to a data transfer once it asserts IRDY#, but the target can still
do
> whatever it wants. That implies the master and target are not created
equal,
> which is fine.
> >
> > Richard Yuan
> >
> > >>> "Weng" <wtx@umem.com> 4/16/01 >>>
> >
> > Hi,
> > Thank you for every response. I think this one is the best answer to my
> > question.
> >
> > Weng
> >
> > ----- Original Message -----
> > From: Srikiran Dravida <SrikiranD@ami.com>
> > To: <wtx@umem.com>; <pci-sig@znyx.com>
> > Sent: Saturday, April 14, 2001 11:39 AM
> > Subject: RE: why Target cannot change its mind
> >
> > Hi!
> > I think this will lead to more waitstates being inserted in a
> > transaction.. To stretch the point it could lead to infinite waitstates
> for
> > a data transaction.
> > Assume the scenario, master inserts a waitstate. Seeing this target
> asserts
> > a waitstate, looking at this master can insert another waitstate in the
> next
> > clock. It can go on like this with out a data transaction...
> >
> > - SriKiran Dravida,
> > Sr ASIC Design Engineer,
> > American MegaTrends Inc,
> > 6145-F, Northbelt Pkwy,
> > Norcross, GA-30092.
> > 770-246-8600 ( X7110)
> >
> > > -----Original Message-----
> > > From: Weng [SMTP:wtx@umem.com]
> > > Sent: Friday, April 13, 2001 7:40 PM
> > > To: pci-sig@znyx.com
> > > 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 <mailto:wtx@umem.com>
> > > wengtianxiang@yahoo.com <mailto: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
<mailto:small@quicklogic.com>>
> > > To: < wtx@umem.com <mailto:wtx@umem.com>>; < pci-sig@znyx.com
> > > <mailto: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 <mailto: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 <mailto:wtx@umem.com>
> > > > wengtianxiang@yahoo.com <mailto: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
> > > <mailto:groudier@club-internet.fr>>
> > > > To: Weng < wtx@umem.com <mailto:wtx@umem.com>>
> > > > Cc: < pci-sig@znyx.com <mailto: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 <mailto:wtx@umem.com>
> > > > > wengtianxiang@yahoo.com <mailto:wengtianxiang@yahoo.com>
> > > > >
> > > > > Micro Memory Inc.
> > > > > 9540 Vassar Avenue
> > > > > Chartsworth, CA 91311
> > > > > Tel: 818-998-0070
> > > > > Fax: 818-998-4459
> > > >
> > > > Gérard.
> > > >
> > > >
> > >