05-13-2008 07:40 AM
For a bigger project, I'm trying to build up a sample system, where a Spartan3 is connected by PCI to a host processor which needs to control some GPIOS. My best guess is to use the plbv46_pci core (PLB master) and the xps_gpio core (PLB slave). More peripheral will come later in the design.
Practically, I need a PLB system where there's no microprocessor.
Is this feasible? Does anybody have any kind of experience with this? Do you have any hints about the design flow ?
Thanks in advance for your support.
05-14-2008 01:06 PM
It is possible to create a system using PLB peripherals without a processor in EDK as long as the bus has at least one master and one slave. You will be able to generate a functional bitstream. The only caveat is that EDK IPs have not been tested in such an environment (without processors), so the performance/operation cannot be guaranteed. This is something you will have to watch out for.
05-15-2008 12:10 AM - edited 05-15-2008 12:11 AM
Your approach may be appropriate if you are later planning on adding a processor system to the FPGA.
But if you simply need a PCI target to GPIO design, I would suggest the PLBv4.6 bridge to PCI bridge and XPS GPIO peripheral is overkill.
There have been many PCI designs done without XPS.
-generate the PCI core in CoreGen
-look at its example back-end ping design, understand the interface, and what it is doing (it includes a back-end design, documentation, batch file for synthesis/implementation, etc.)
-modify the reference design to add some GPIO
-The user guides (http://www.xilinx.com/support/documentation/ipbusinterfacei-o_pci_do-di-pci32-ip.htm) will also be useful.
The is a much more common approach than using the XPS peripherals without an FPGA-based processor.
05-15-2008 02:30 PM
To be fully honest, the system I'm building is just the first of a product family. The customer will add new peripherals and eventually use an integrated processor core.
The best way to make this possible is to give him a platform that can be easily expanded. And this is what I'm planning to do.
I have evaluated the approach you suggest timpe (and I have enough experience to design it easily), but it's not matching my vision.
Just my two cents, suggestions are welcome.
05-15-2008 02:46 PM
Given your additional information, I am inclined to agree with you. ;)
I just wanted to make sure that I wasn't ommiting a simpler option that could work if "ease of development" was more important than "system flexibility".
It is generally better to have a few approaches to evaluate to see what makes sense for your specific design.