[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PCI 2.2 protocol question (FRAME# and Latency Timer timeout)
On Tue, 17 Oct 2000, Weng Tianxiang wrote:
> You may change the code as follows, as it is very simple:
> 1. At the first cycle, you assert FRAME# as usual;
> 2. On the clock when your data is ready and you are going to assert IRDY#,
> deassert FRAME# and assert IRDY# at the same time, that means output data is
> ready and it's the last data cycle in the transaction.
> 3. After Target assertes TRDY#, you deassert IRDY#, that means your
> transaction is over.
Hmmm... You seem to describe how a master must behave when it only intends
to perform a single data phase. I am not sure that this applies to the
My understanding of the issue is the following:
(Sorry in advance if it is incorrect)
1) Since both FRAME# and IRDY# are asserted on some cycle 2, the master
is committing its intention to perform at least 2 data phases. But no
data phase occurs due to TRDY# being deasserted on this cycle.
2) By deciding to deassert FRAME# on the next cycle, the master runs
the risk to change its committment to a single data phase if the
target does not assert TRDY# on this next cycle. Btw, it is what
happens in the problem description, and such a change in mind from
the master may well hurt PCI fundamentals.
A target that does actually consider situation (1) on cycle 2 as a real
commitment for at least 2 data phases may elect to actually perform the
read of 2 DWORDS and move them to some buffer, keeping TRDY# deasserted.
If on cycle 3, the master changes its mind for a single final data phase:
- The target will only send the first DWORD to the master.
- The second DWORD will be discarded and the master will not even
be aware of it to having been read.
When this happens to a non prefetchable area, the side effect due to
the prefetching of DWORD 2 may lead to serious problems.
> Weng Tianxiang
> Micro Memory Inc.
> 9540 Vassar Av.
> Chatsworth, CA 91311
> Phone: 818-998-0070, Fax: 818-998-4459
> ----- Original Message -----
> From: Sachin Kadu <firstname.lastname@example.org>
> To: <email@example.com>
> Sent: Monday, October 16, 2000 9:52 PM
> Subject: Re: PCI 2.2 protocol question (FRAME# and Latency Timer timeout)
> > Hi,
> > I am interested in knowing what will be the solution if you are
> > to change the code?
> > Please reply.
> > sachin
> > > ----- Original Message -----
> > > From: Simi Valecha <firstname.lastname@example.org>
> > > To: <email@example.com>
> > > Cc: <firstname.lastname@example.org>
> > > Sent: Friday, October 13, 2000 4:58 PM
> > > Subject: Fwd: PCI 2.2 protocol question (FRAME# and Latency Timer
> > >
> > >
> > > > I have a PCI protocol question for our PCI master
> > > > design. We are getting a protocol violation if we use
> > > > our vendor simulation monitor, but I am not sure if it
> > > > a real problem or not. In case it is not a real
> > > > problem, we would prefer not to change our RTL this
> > > > late.
> > > >
> > > > The problem is the following:
> > > > The master Latency Timer expires on cycle 2, while
> > > > GNT# to the master is deasserted on cycle 2. Both
> > > > IRDY# and FRAME# are asserted on cycle 2. However, the
> > > > slave on the bus inserts a wait state here and
> > > > deasserts TRDY# on cycle 2. Currently, our master
> > > > deasserts FRAME# on the next cycle (cycle 3) while
> > > > keeping IRDY# asserted. However, our EDA vendor
> > > > monitor says that we are violating the following
> > > > requirement: "Once a master has asserted IRDY# it
> > > > cannot change FRAME# until the current data phase
> > > > completes (3.2.1)".
> > > >
> > > > We think that there is no violation because the last
> > > > line of the second paragraph on p.50 of the spec (Sec.
> > > > 220.127.116.11) suggests that even if TRDY# was deasserted,
> > > > FRAME# could be deasserted (as long as IRDY# is kept
> > > > asserted).
> > > > Can someone please clarify if it is safe for us not to
> > > > change our design? And if we don't, what could be the
> > > > potential implications? Or should we bit the bullet
> > > > and change our RTL.
> > > >
> > > > Thanks a lot!
> > > >
> > > > -Simi
> > > > email@example.com
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Get Yahoo! Mail - Free email you can access from anywhere!
> > > > http://mail.yahoo.com/