Re: [pci] IRDY & TRDY

[cfk <cfk@pacbell.net>]

Dear Miha:
    Here is revision B of my IRDY/TRDY drawing showing CLk33, FRAME, DEVSEL,
IRDY, TRDY, AD & CBE. I tried to take care with the timing to show the
relationships correctly. In this case, this is the configuration write that
is failing. The master initiating this write to the PCI_BRIDGE32 core is
asserting FRAME, IRDY, AD, CBE. The signal CLK33 is generated inside the
FPGA and provided to both the PCI_BRIDGE32 module and is output on a PCI
connector pin to the Intel XScale board containing an 80200/80312
combination and the configuration transaction is initiated from that end.

    I have commented out the irdy_reg_in statement in the gate that asserts
load_to_conf_out and I can write to the PCI_BRIDGE32 and am continuing with
my developement. But I would appreciate it if we can get to the bottom of
this one so I can finally close my lab notebook on this page.

Charles

----- Original Message -----
From: "Miha Dolenc" <mihad@opencores.org>
To: <pci@opencores.org>
Sent: Tuesday, July 16, 2002 3:43 AM
Subject: Re: [pci] IRDY & TRDY


> Hi!
>
> PCI specification specifies hold time of 0, so IRDY de-asserting 2ns after
> rising CLK edge is alright.
> I saw the TRDY in the pdf you sent and it really looks strange.
> Where is TRDY signal coming from at this picture?
> Is it measured on the bus or on the spare pin of the FPGA?
> Do you have all timing constraints set up correctly and are they met by
the
> PAR tool?
>
> The picture you sent is really strange. As I can see, IRDY is asserted for
2
> rising clock edges. What is the setup time of IRDY on the first clock
edge?
> Maybe TRDY and load_to_conf_out become metastable because IRDY asserts too
> late. Setup time should be 7ns at 33MHz clock.
> If this is OK, then it looks like if TRDY output Flip-Flop receives a
clock
> edge too early and asserts. This can be caused by large clock skews, but
I'm
> sure  this isn't the case, if you are using global clock buffer in the
FPGA.
> Another strange thing is TRDY de-asserting when IRDY is de-asserted (3rd
> clock edge on your picture). This is not allowed!
>
> I'm really interested in this problem, so I hope you will keep working on
> it.
> Do you have any means of sampling the whole progress of the configuration
> cycle (only control, not data signals). I would really like to see
> everything that's going on (FRAME, DEVSEL, IDSEL, IRDY, TRDY etc.) with a
> few timings to come with it. Maybe I would have a better answer to your
> problem as opposed to answering you with a question.
>
> Hope to hear from you soon!
>
> Regards,
> Miha Dolenc
>
> ----- Original Message -----
> From: "cfk" <cfk@pacbell.net>
> To: <pci@opencores.org>
> Sent: Friday, July 05, 2002 11:25 AM
> Subject: [pci] IRDY & TRDY
>
>
> > Dear August Gentlemen of the order PCI:
> >     I have spent a bit of time now trying to figure out why my pci
> > configuration reads are working just fine, but I cannot seem to issue
any
> > configuration writes to PCI_BRIDGE32 yet. In my particular case, I have
> the
> > bridge defined as GUEST and I have loaded it into a VirtexE-2000 FPGA.
In
> > addition the FPGA sources CLK33, RST and contains an arbiter. Connected
to
> > this FPGA is a PCI add-in card from Cyclone Microsystems containing an
> Intel
> > 80200/80312 XScale system running vxWorks.
> >
> >     Now here's the deal. After some gnashing of teeth and setting up the
> > core so I can output test points from within PCI_TARGET32_SM, I can see
> that
> > load_to_conf_out is not asserting when it should in order to enable
> > pciu_conf_wenable_out, when drives w_we into CONF_SPACE in order to
> actually
> > write the new status/command value into register 0x4 in configuration
> space.
> > That's the 32 bit register which is the concatenation of
{status,command}.
> I
> > can see on my logic analyzer that  pci_irdy_reg_in and bckp_trdy_reg are
> > asserted, but they are one CLK33 displaced in time, so they are not both
> > asserted for the same time (actually not quite true, they are both
> asserted
> > for <2NS, but that is insufficient for the logic to work).
> >
> >     It my particular system, TRDY is asserted just before CLK33 rises
(by
> a
> > few NS) and IRDY is de-asserted by the master issuing the configuration
> > write just after CLK33 rises. By the way, this is true for both
> > configuration reads and writes. It is just the writes that are not
> > succeeding. The reads are just fine. I am suspecting that on
configuration
> > writes, that the master is pushing the PCI specification by de-asserting
> > IRDY less then 2NS after CLK33 rises. I am also further suspecting that
> > PCI_BRIDGE32 will work fine in most applications, but when the other
> device
> > on the PCI bus is pushing the PCI specification, it may have trouble
> keeping
> > up.
> >
> >     I have the greatest of respect for this Verilog code after studying
it
> > for most of the last month. I am not complaining or whining, I am just
> > trying to understand what is happening so I can fix it. Maybe something
> else
> > is causing my logic not to work, but I am putting my current thoughts
out
> to
> > this group in hopes of some guidance towards understanding. I am
attaching
> a
> > PDF file of a portion of the Orcad schematic I have drawn of the bridge
> > logic in hopes that one of you gentlemen will help me come to a useful
> > resolution so I can go back to work on Monday with a plan to proceed.
> >
> > Charles Krinke
> >
> > p.s. I'm interested in knowing if the schematic I tossed out last
weekend
> > was useful to anyone. I have figured out how to write it as a PDF file
in
> > the last week and will be happy to share it with anyone who wishes. I
may
> > end up putting it on my web site, or Miha may put it on opencores if he
> > thinks it is useful enough. I have 10 more hours in it since last
weekend,
> > so it has made some progress. This is only one minor page.
> >
> >
>
>
> --
> To unsubscribe from pci mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

TRDY.pdf