Re: PCI 2.2 protocol question (FRAME# and Latency Timer timeout)

["Weng Tianxiang" <wtx@umem.com>]

Hi,
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.

Weng Tianxiang
Micro Memory Inc.
9540 Vassar Av.
Chatsworth, CA 91311
Phone: 818-998-0070, Fax: 818-998-4459

----- Original Message -----
From: Sachin Kadu <sachin@controlnet.co.in>
To: <pci-sig@znyx.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
allowed
> to change the code?
>      Please reply.
>                                   sachin
>
> > ----- Original Message -----
> > From: Simi Valecha <simi_valecha@yahoo.com>
> > To: <pci-sig@znyx.com>
> > Cc: <simi_valecha@znyx.com>
> > Sent: Friday, October 13, 2000 4:58 PM
> > Subject: Fwd: PCI 2.2 protocol question (FRAME# and Latency Timer
timeout)
> >
> >
> > > 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.
> > > 3.3.3.1) 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
> > > simi_valecha@yahoo.com
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get Yahoo! Mail - Free email you can access from anywhere!
> > > http://mail.yahoo.com/
> > >
> > >
> > >
> >
> >
>
>