Hi all,

I need a PCI target only core, for a new board that includes also other
peripherals (registers, counters and manchester encoder/decoder) inside
the same fpga.
On opencores there are two solutions:
PCI Bridge
PCI Target
I prefer to use the PCI Target, because it looks more similar to what I
need, and because it is written in VHDL which I am more confident with.
My concern is that the PCI Target is marked as Beta.
The PCI Bridge is for sure more complete, documented and it is marked as
Complete & tested, but also has much more that what I need (PCI master
and WB Slave).

What are the problems in using the PCI Target? Are there any known
problems, or unimplemented features? Anyone is actually using it?

On the other side, is it possible to tear down the full PCI Bridge with
only the functionality I need (some ifdefs, maybe)?

Any other suggestions?

Thanks all.
Mau.

On Mon, Mar 26, 2007 at 03:08:20PM +0200, Mau Liste wrote:


A simple test would be to just input all zeros on the wishbone master
side and see how much of the design that is optimized away by the
synthesizer...

/Andreas

Thanks for your reply.
I tried that. The problem is that you need to do the same on the PCI
side, and it is not so clear to me how to do it.
As an example, take the pci_frame signal. On a target only, this is an
input, but the full bridge have three signals instead:
pci_frame_i : in std_logic;
pci_frame_o : out std_logic;
pci_frame_oe_o : out std_logic;
It looks like it is possible to connect only the pci_frame_i leaving the
others disconnected. More difficult is the pci_par that still needs to
be a full io.
Anyway, I tried to do that also on the pci side, and I get a lot of
warning about removed logic ... good.
What I don't know is if the remaining logic is still working :(
I tried a few simulations and seems nothing is working.
So the question is: has anybody tried that?

Thank you.
Mau.

Andreas Ehliar wrote:

Mau Liste wrote:




* only 1 BAR
* 16-bit wishbone interface
* no burst transfers

The optimiser does a reasonable job without having to tear anything out. For a previous design we used bus mastering and the core was 2848 LEs on a Cyclone II platform. In a current design we're only using it as a target, and it's 1804 LEs (same silicon). We didn't bother disconnecting anything at all (other than slave-side wishbone buses of course) because atm we aren't short of resources. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266

Mark McDougall wrote:


I have seen also that PAR is an output only so it does look like it can
only generate parity and not check it.

For this application, I can probably accept these limitations. But aside
from limitations ... does it work? It doesn't look much
maintained/documented, so I want to check if I am alone on that road, or
if there are others to share comments/bug fixes with.




The optimiser does a reasonable job without having to tear anything out.

Mau Liste wrote:



No idea - we couldn't live with the limitations...


The optimiser does a reasonable job without having to tear anything
out.

Thanks all for the suggestions ... I think I will continue to try with
the full bridge.
I will come back for news or other questions.
Thanks again.
Mau.

Mark McDougall wrote:

I've see that, but what remains after tying unused input to gnd, does
not look much working (just tried few simulations). But I will
continue to check ...