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

Re: Can this reliably work on PCI bus?



Well, it worked for us too but then suddenly when DSP software had changed
stopped working. I know it seems to point to the DSP software but I proved
with a logic analyzer that it is not the DSP who is messing things up. I
have an analyzer looking at the local bus between the DSP and PCI controller
and it is all fine there...

The data we are reading is static and is not expected to change. DSP fills
out memory once and never touches it anymore. Every time we have a bad read,
next time we read good data from the same location... Electrically,
timing-wise etc., everything looks fine.

============================
Mikhail Matusov
Hardware Design Engineer
Square Peg Communications
Tel.: 1 (613) 271-0044 ext.231
Fax: 1 (613) 271-3007
http://www.squarepeg.ca



----- Original Message -----
From: Stefan Ivanov <Stefan_Ivanov@spectrumsignal.com>
To: <pci-sig@znyx.com>
Sent: Friday, February 15, 2002 4:49 PM
Subject: RE: Can this reliably work on PCI bus?


> In general, it should work. We are doing it and it is OK.
>
> Are you sure it is the read that is going wrong and you are not writing
the same data into two consecutive addresses, or overwriting the data in one
address with the data intended for the next address?
> ============================
> Stefan Ivanov,
> Hardware Development Engineer
> Spectrum Signal Processing
>
>
> > -----Original Message-----
> > From: Tor Tovsland [mailto:tor@comuniq.com]
> > Sent: Friday, February 15, 2002 1:23 PM
> > To: pci-sig@znyx.com
> > Subject: RE: Can this reliably work on PCI bus?
> >
> >
> >
> >
> > I have seen something similar. You have to make sure that all accesses
> > are finished before starting a new one, in other words all accesses
> > (read and write) have to be serialized. There are some "undocumented
> > features" with TI's HPI that can cause the behavior that you see. You
> > might wanto to look for high priority threads or interrupts (on host
> > side) that will interrupt lower priority accesses, and then
> > switch back
> > to the lower priority ones again. That will make the auto-increment
> > feature "skip" an access, which sounds to be what you are seeing.
> >
> > ______________________________________________________________
> > __________
> > Tor Tovsland                                        Comuniq, Inc.
> > Sr. Software Developer, i960 Group                  2046 Samco Rd.
> > tor@comuniq.com                                     Rapid
> > City, SD 57702
> >                                                     USA
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mikhail Matusov [mailto:matusov@squarepeg.ca]
> > Sent: Friday, February 15, 2002 12:23 PM
> > To: pci-sig@znyx.com
> > Cc: cpci@patriot.getnet.net
> > Subject: Can this reliably work on PCI bus?
> >
> >
> > Hi all,
> >
> > I have a cPCI board with a TI TMS320C6xxx DSP on it. The
> > board is a PCI
> > target only and we access DSP through its host port, which is
> > made up of
> > two
> > registers: address register and data register. Thus, every transaction
> > splits into two: first one has to put an address into the address
> > register and then data can be read or written to/from the
> > data register.
> > Everything worked fine till recently we started seeing some errors
> > during read cycles. Errors are such that occasionally we receive data
> > from either address n+1 or
> > n+2. I think I have to mention that the system (into which
> > we plug  our
> > card) has a 21154 PCI-to-PCI bridge (not the latest buggy
> > revision). My
> > suspicion is that because our write and read memory transactions are
> > always from the same address what we are seeing is some kind of
> > transaction reordering happening in the bridge. We tried
> > reading address
> > back first before reading data from the data register, this seemed to
> > decrease frequency of errors but did not fix the problem completely.
> >
> > So, I was wondering whether I am on the right track and whether this
> > thing can work at all?
> >
> > Thanks,
> > ============================
> > Mikhail Matusov
> > Hardware Design Engineer
> > Square Peg Communications
> > Tel.: 1 (613) 271-0044 ext.231
> > Fax: 1 (613) 271-3007
> > http://www.squarepeg.ca
> >
> >
> >
>
>