spartan6 pcie endpoint looks incomplete

hi

im trying to make a pci-express peripheral card (ADC, DSP and some local DDR2) with the xilinx spartan-6 FPGA.
The xilinx coregenerator generates a PCIe IP, bit to me it seems it is an incomplete IP core. What they call as user interface, i would call internal signals of an IP core. Its not just that i need to write a back-end interface, but the pci-express protocol handling and packet-assembling also has to be coded by the user. They provide a reference design, but instead of implementing a standard back-end interface, they use a commercial third party custom-logic block connected to the pcie core, which makes it to be not reuseable.

i think its a completely wrong view from xilinx. the point in using IP cores is that they save the user from the need of dealing with interface protocol on one side of the interface bridge. this core is like a half-done ip core, but if i want to code the second half, then i need to understand the the internal details of the already implemented part, which is a waste of time.

is there an open-source project that i could reuse to make my system? i need a pcie-to-wishbone IP with two wishbone buses (BAR0 and BAR1).

i have ise 11.4. did they implement a more useable ip in the new 12.x coregenerators?

Hi buenos,

Short answer about coregen design (PIO): NO, you still need to do some work to interface to PCIe block to your wishbone. Everything depends on your motivation - it's not a rocket science

Have you tried to dig into the code/doc of the XAPP 1052, XAPP 859, and S6 connectivity kit ?

Do you plan to use the DDR2 for ADC buffering ?

Do you plan to use PCIe Endpoint as a Bus Master or Bus Slave? Single write/reads, or block transfers, or both?

Cheers,
mhmhmh

hi the application would work this way:
1. user sets a bit through pci, to start adc
2. adc takes 128M samples ans stores to DDR memory
3. ADC asserts either a bit that can be polled through pcie, or ann irq
4. user software reads the DDR content DWORD by DWORD in single accesses through pcie.

actually i have found the PIO ref design in the coregen result folder, although it is configured for a 8kB window. i was trying to tweak it to widen the address bus, but i will have to test it and debug on a protoype.
At first i want to make a pcie-to-wb core with a 256MB image that i can easily pop into any FPGA project using a SP6-LX45T.


what is missing from the base core is called "transaction layer logic".

buenos said:

hi the application would work this way:
1. user sets a bit through pci, to start adc
2. adc takes 128M samples ans stores to DDR memory
3. ADC asserts either a bit that can be polled through pcie, or ann irq
4. user software reads the DDR content DWORD by DWORD in single accesses through pcie.

actually i have found the PIO ref design in the coregen result folder, although it is configured for a 8kB window. i was trying to tweak it to widen the address bus, but i will have to test it and debug on a protoype.
At first i want to make a pcie-to-wb core with a 256MB image that i can easily pop into any FPGA project using a SP6-LX45T.


what is missing from the base core is called "transaction layer logic".

Click to expand...

Hi buenos,

How about this way ?

The XAPP 859 should be fine for the first try, it moves a data from DDR2 mem space, into the system memory space (PC). You could put a mux in-between the PCIe engine and DDR2 memo controller, which allows you to load the DDR2 with the ADC data, and then move that data into system memory.

a) You arm your ADC by writing to some config register. The ADC pushes the data into the DDR2 memory, when your 128 M is done, your PCIe IP pushes the data to system memory, asserting the interrupt at the end of the transfer.

b) The system host gets the interrupt, and it sends back single write to notify the PCIe IP to de-assert the interrupt, then it starts processing the data stored already in it's memory.

c) You write again to some config register which starts the whole procedure again.

The first most important thing to do would be to put the XAPP 859 into the simulation, so you can see the interaction of the blocks. I think this a nice design to start with.

Hope that helps
Cheers

hi.
thanks for the suggestions.
my problem with the xilinx reference designs is that they are optimized for one particular application and not really commented what they are doing. i wanted to reuse the PIO ref design supplied with coregenerator, but then i gave it up, since i didnt fully understand what was going on inside it. to change the refdesign, a full understanding is necessary.
the other thing is the first stage of my project is to create a reuseable pcie-to-wishbone IP. this core has to work with any of the opencores IPs. My previous pci-to-wishbone core was tested with a few cores from opencores and worked nicely, putting the systems together was completely painless, since the pci3wb core had a universal bus back-end interface, not a 1000-signal custom interface like xilinx implements sometimes.
so at the weekend i was coding the TLP processing and the wishbone back-end interface. its almost done, and at least in this code i fully understand what is going on.