PCI master on a low budget
Edward Cheffetz
time/money. We did an AMCC/Xilinx board for a camera interface, but AMCC
seems to be giving up that business, and to make matters worse, now I
need to do a digital camera board since that board was for an analog
camera which it now appears will not be released. So I need to implement
a PCI master - I plan to use the Xilinx since I have their Foundation
Base Express package. Can anyone help me get some VHDL code for this or
give me any suggestions? My VHDL experience consists of the two day
Xilinx course and a few attempts at counters and multiplexers, Thank
you.
--
Edward Cheffetz
iPeripherals
860 236-2406
FAX 860 233-4949
Joel Kolstad
news:38F5E040...@iperipherals.com...
> I am trying to help a very poor customer, at this point on my own
> time/money.
> a PCI master - I plan to use the Xilinx since I have their Foundation
> Base Express package. Can anyone help me get some VHDL code for this or
> give me any suggestions?
Don't do it in the FPGA; you'll definitely spend a lot more time getting it
working. Even the Xilinx PCI cores are nowhere near as feature-ladden or
easy to use as something like a PLX Technologies PLX9054 (this is what we
eneded up using). Although this isn't an advertisement for PLX Tech., a
'9054 pretty much just works and it wasn't that difficult to eventually get
ahold of a Real, Live Engineer at PLX Tech. when we had problems.
PLX Tech. is a pretty small company, and it doesn't seem to me that they're
about to (or even able to) abandon the PCI interface market the way AMCC has
slowly done. (Although, to give AMCC some credit, they were never really
trying to get _into_ the PCI interface market in a big way, and once they
found themselves there, apparently were never fully convinced that something
good had transpired...)
A '9054 gets you two DMA engines built-in, one of which has synchronization
pins leading right to the pins. (The other DMA engine you write to the
'9054's internal registerrs to get going, and the first one can use this
approach as well.) The DMA engines are pretty fancy, supporting
scatter/gather lists, which is pretty requisite for systems using virtual
memory if you want reasonably efficient transfers.
About the only downside I can think of with PLX is that the documentation
isn't always that great. The data book improved noticeably since the first
edition we had in 1999, but it's still kind of a jumble in places. (We like
to joke at work that it's at least better than a lot of our own internal
documentation, however. :-) ) This is why being able to find a Real Live
Engineer at PLX Tech. is important.
'9054's go for something like $27 in low quantities in the the PQFP package.
Hopefully this isn't going to break your customer's budget.
---Joel Kolstad
Andy Peters
>Don't do it in the FPGA; you'll definitely spend a lot more time getting it
>working. Even the Xilinx PCI cores are nowhere near as feature-ladden or
>easy to use as something like a PLX Technologies PLX9054 (this is what we
>eneded up using). Although this isn't an advertisement for PLX Tech., a
>'9054 pretty much just works and it wasn't that difficult to eventually get
>ahold of a Real, Live Engineer at PLX Tech. when we had problems.
Joel,
Does PLX offer a VHDL model of that part? A behavioural model of the local
side would be wonderful.
-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu
"Money is property; it is not speech."
-- Justice John Paul Stevens
Joel Kolstad
local
> side would be wonderful.
To my knowledge, they don't. That would be nice.
What we did was to write a very simple bus-level "PLX simulator" (which
really means "i960 bus level simulator," as we're using the 9054 in mode J)
that runs the local bus and interface through so-called "local bus data
buffer" VHDL records. I ended up with test code like this:
b:=DMADesc(DMACh=>0,Addr=>x"1000"*64,Width=>5,Pitch=>11,Height=>5,RxW=>'0');
b:=b&DMADesc(Addr=>x"5678"*64,Width=>1024/64,Pitch=>-4096/64,Height=>3072,Rx
W=>'1');
RunLB(b);
ReadRegister(RegAddr(MEM_FU,MemSPXP_Reg),d);
WriteLine("SPXP register: " & XHexImage(d));
This code is initializing some control fields in a DMA engine inside of an
FPGA and then reads back a status register in that DMA engine. On the third
line, "RunLB" will make the "PLX simulator" do a burst write of 8 DWords
(DMADesc() returns a 4 word burst). The ReadRegister() routine creates a
local bus data buffer that's one entry deep and then calls RunLB.
This approach has worked well in simulation, but of course you don't gain
any of the true power of the PLX 9054 such as its DMA engines and it makes
the rather large assumption that we correctly implemented the PLX simulator.
---Joel Kolstad
Andy Peters
>local
>> side would be wonderful.
>
>To my knowledge, they don't. That would be nice.
Yes, indeedy. Truly, having behavioural (or behavioral) models can be the
tie-breaker when choosing parts.
>This approach has worked well in simulation, but of course you don't gain
>any of the true power of the PLX 9054 such as its DMA engines and it makes
>the rather large assumption that we correctly implemented the PLX
simulator.
I made some rather large assumptions about the Cypress VME chip set my
current board is based around, and wrote a fairly simple VHDL model (there
is a company out there that made one, but at $5K, it's more expensive than
the signal-integrity software I really want!). The assumptions were mostly
correct, but there were some things that weren't clear. Nothing that a
couple of white wires couldn't fix (he says whilst the ace tech is adding
white wires).
On a Pentium III/550 with 384MB RAM, the post-route simulation with three
FPGAs, eight SDRAMs and the VME interface chip takes about ten minutes to
run 600 us simulation time. Yowza. But it matches the logic analyzer.