Re: [pci] IRDY & TRDY

["Miha Dolenc" <mihad@opencores.org>]

Hi!

I can say 99% sure, that you have a problem with the PCI clock generation,
trace lengths or something of this sort.
As I can see, the PCI master initiating the configuration cycle is doing
everything as it is supposed to. Target signals are all messed up, but this
is not the design problem - as you probably know all PCI bus outputs in a
bridge are registered, so there is no way, that DEVSEL, TRDY etc. can change
state just a few ns before rising clock edge.
You say, that PCI clock is generated internally - in the FPGA. Is this done
with a DLL? Even if this is true, it is not balanced - FPGA flops receive it
before other ICs in your system. If you have no other way of supplying the
clock to PCI bus, you should try with board level de-skew of the clock
generated by the FPGA. I have read some papers regarding that on Xilinx's
web site some time ago.
And I'm sorry to say that, but if you continue with a development before you
(with our help, I hope) take care of this, you probably wont get far, unless
you are really lucky ;-)

Regards,
Miha Dolenc

----- Original Message -----
From: "cfk" <cfk@pacbell.net>
To: <pci@opencores.org>
Sent: Friday, July 19, 2002 11:04 PM
Subject: Re: [pci] IRDY & TRDY


> 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
> >
>


--
To unsubscribe from pci mailing list please visit http://www.opencores.org/mailinglists.shtml