[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pci] IRDY & TRDY



Heya !

just to let everyone - Miha and Tadej are on vacation until mid July.

regards,
Damjan

----- Original Message -----
From: "cfk" <cfk@pacbell.net>
To: <pci@opencores.org>
Sent: Friday, July 05, 2002 8:25 PM
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