[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why Target cannot change its mind

To: <pci-sig@znyx.com>
Subject: Re: why Target cannot change its mind
From: "Weng" <wtx@umem.com>
Date: Tue, 17 Apr 2001 08:29:46 -0700
References: <4A78850EF802D211BB3900805FFE55550172FB3F@atl_es1.megatrends.com>
Reply-To: wtx@umem.com
Sender: owner-reflector@www.pcisig.com

Hi Srikiran,
The same 16/8 cycle limit as PCI's if you neglect any inserting wait cycle
introduced by my method.

Weng

----- Original Message -----
From: Srikiran Dravida <SrikiranD@ami.com>
To: <wtx@umem.com>
Cc: <pci-sig@znyx.com>
Sent: Monday, April 16, 2001 3:01 PM
Subject: RE: why Target cannot change its mind


Weng,
   The 16 cycles/ 8 cycle limit is for assertion of TRDY# from FRAME#  or
IRDY# . But in the "deadlock" situation you are asserting TRDY#  within 16/8
clocks, but there is no data transaction as IRDY# is deasserted in this
clock. So they have two choices to take away the "deadlock"
 1. Stricter 16/8 cycle limit which will complete the data phase
 2. Stricter assertion rules for TRDY# and IRDY#.

  They chose the 2nd.

- 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: Monday, April 16, 2001 2:42 PM
> To: pci-sig@znyx.com
> Subject: 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.
> > > > >
> > > > >
> > > >
>
References:
- RE: why Target cannot change its mind
  - From: Srikiran Dravida <SrikiranD@ami.com>
Prev by Date: FWD: FW: PCI Configuration Registers accessed by 3rd device and not PCI Host
Next by Date: Test
Prev by thread: RE: why Target cannot change its mind
Next by thread: Re: why Target cannot change its mind
Index(es):
- Date
- Thread