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

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