uC-less system

[fabrizio.salidu@accent.it]

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. 

[centaur19]

Fabrizio,

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.

[barriet]

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.

You could:

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

Cheers,

bt

Message Edited by timpe on 05-15-2008 03:11 AM

[fabrizio.salidu@accent.it]

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. 

Fabrizio 

[barriet]

Fabrizio,

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.

Good luck,

bt