[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why Target cannot change its mind
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.
> >
> >
>