knjn's FPGA-PCI: is it a good deal?

[DiTBho]

my Atlas board supports MIPS32 and MIPS64 (and the MIPS5++ prototype) cpu boards, and comes with two PCI slots. One is 3.3V-only 32-Bit@66Mhz, the other is 3.3V/5V 32-Bit@33Mhz.

So, nothing special, old pretty 2000s-ish standard.

I'd love to develop something custom to experiment with my-c compiler (kind of C89 but revisited), so I am looking for a FPGA-PCI card to play with a different model of "tr-mem" (to be implemented with FPGA's BRAM), and found this one made by Knjn.

It is quite old, made in 2006, and specs are nothing special, but at least the small XC2S100 fpga is "enough" for my needs.

Dragon PCI FPGA, Specs
- Xilinx's FPGA Spartan-II XC2S100, plus FPGA boot-PROM.
- PCI bus (32 bits/33MHz) with target mode reference design.
- USB interface to the FPGA (about 1MBytes/s max sustained), and USB controlled I2C master.
- download/communicate with the FPGA
- program the FPGA boot-PROM
- download the 8051
- control the I2C
- 10BASE-T Ethernet with reference design.
- JTAG interface.
- Top and bottom SIL connectors (can plug into a wide 'solderless-breadboard' for experiments)
- and dual-row connectors (can be used as motherboard for other projects).
- 8051 microcontroller (on the back of the board). Use of the 8051 is optional.
- When in use, the 8051 and FPGA can communicate through an 8-bits synchronous bidirectional bus.
- FlashyD compatible (what? kind of acquisition board).

I've only played PLX chips, which export the PCI to a simple-ISA bus, so I have always delegated all the PCI interfacing-job to this type of "bridge" chips and this card seems like a good opportunity to play PCI games on a more intimate level.

The seller promotes

The FPGA is directly connected to the PCI bus, no complicated interface (PLX...). A target mode reference design is provided

and that "directly connected" (also thanks to spartan 2 being 5V tolerant) sounds good, doesn't it? 

Unfortunatly ... they say "provided" but you cannot see any HDL/C source untill you buy the card, which is a bit ... a bit of a risk because that card is not cheap considering you have to "import" it (customs fees to be paid).

(~250 euro paid to have it on my door)

What do you think, guys? Has anyone played that card yet? Or, any alternative?

Let me know, thanks




p.s.
is there anything similar but for "miniPCI" ?
(just in case ... my MIPS-router will be jealous of its MIPS *big* cousin board)

[langwadt]

if you don't need any peripherals, maybe: http://store.mesanet.com/index.php?route=product/product&product_id=55

[mblinov]

If you're asking how hard it would be to implement a PCI interface from scratch, the answer is probably mostly not that hard but a bit tedious.

"PCI bus demystified" by Doug Abbot makes a really good complement to the official PCI spec. Just try googling for it.

I did something similar with an old ProASIC3, but it didn't have any physical PCI interface - it was just a typical dev board. I actually ended up soldering it point-to-point to the back of an old Athlon64-powered motherboard, and managed to get configuration space read transfers to work... with a one liner change to the kernel first (for some reason, it returned all '1's upon first initialization.)

The PCI interface was written from scratch in VHDL, but I never did get it to completion. I found Conventional PCI to be quite full of weird quirks that made implementing it more difficult.

The worst is that its a bidirectional bus, so you have these turn-around cycles everywhere where you will need to go from high-Z driving to actually driving, and vice-versa all the time.

The way the host determines what size of a BAR window to give you, is by writing all ones to your BAR config registers, then reading them back, and seeing which bits stayed as a '1', and which were still '0' - basically, the host expects you to ignore BAR address bits that are outside the range of mapping that your device supports. Or something to that end anyway... haven't fiddled with this stuff for over 2 years.

Another thing, this may well be chipset specific: if you leave IDSEL signal hanging, and your PCI gadget is the only thing on the PCI bus (forget that: I just checked the spec and IDSEL is from the host, not the device.) (remember the PCI bus is physically shared between all devices.) The chipset may well decide to turn off the PCI clock to save power. I've had that happen in the beginning, and its a sign that the PCI chipset has decided there's no device on the bus, which implies youre not pulling low one of the PRSNT1# or PRSNT2# signals correctly. from the spec:



Anyway, the point is that all this stuff is documented and in the spec - its just a lot of reading, and chasing down issues in my case was mostly a game of "what detail of the spec did i forget to consider this time".

In any case, even if they don't offer an IP block for it, going about writing a PCI interface is far from impossible and probably quite entertaining (depending on what you consider interesting ofcourse.)

This is what my prototype looked like (i've 'disassembled' it since then). It's probably best to take a few days to make a proper PCI card, or get one ready made! The display is dmesg, showing the PCI device being attached (VID:PID cafe:babe)

[DiTBho]

WOW, very very impressive!
it deserves a full article on Hackaday

"PCI bus demystified" by Doug Abbot makes a really good complement to the official PCI spec. Just try googling for it.

found and ordered a copy on Amazon, thanks 

The PCI interface was written from scratch in VHDL, but I never did get it to completion. I found Conventional PCI to be quite full of weird quirks that made implementing it more difficult.

That's probably why I - albeit on an instinctive level - decided to use a PLX chip in the past to manage the PCI interfacing 

I hacked one of those old NI boards that come with a PLX chip that interfaces PCI on one side and a pair of ADC fifos on the other. I found some on ebay for ~5 UKP each, got a couple.

p.s.
being the dragon FPGA-PCI card a spartanII chip with ~100K LE, how many resources does your PCI interface consume?

According to ISE, my tr-mem vhdl module (plus other stuff I need to synthetize) will consume up to 20% of the chip resources.

[mblinov]

Thanks for your kind words - Maybe this year I should give the project a proper PCB, at the moment its sort of at the bottom of the 'projects bin'...

p.s.
being the dragon FPGA-PCI card a spartanII chip with ~100K LE, how many resources does your PCI interface consume?

According to ISE, my tr-mem vhdl module (plus other stuff I need to synthetize) will consume up to 20% of the chip resources.

I targeted the A3P1000, which advertises itself as "1M logic gates". The Microchip documentation equates that to 11k cells, whereas the old-school Microsemi datasheet refuses to give an esimation.

Having said all that, it gives the "impression" of being on the order of approx a 10k-20k logic cell equivalent device.

From the compile process, the report seems to suggest approx 10% FPGA utilisation, assuming 'CORE' is referring to some measure of the fabric.

Compile report:
===============

    CORE                       Used:   2463  Total:  24576   (10.02%)
    IO (W/ clocks)             Used:     60  Total:    154   (38.96%)
    Differential IO            Used:      0  Total:     35   (0.00%)
    GLOBAL (Chip+Quadrant)     Used:      3  Total:     18   (16.67%)
    PLL                        Used:      0  Total:      1   (0.00%)
    RAM/FIFO                   Used:      0  Total:     32   (0.00%)
    Low Static ICC             Used:      0  Total:      1   (0.00%)
    FlashROM                   Used:      0  Total:      1   (0.00%)
    User JTAG                  Used:      0  Total:      1   (0.00%)

A breakdown of CORE:

Core Information:

    Type    | Instances    | Core tiles
    --------|--------------|-----------
    COMB    | 1574         | 1574
    SEQ     | 889          | 889

In any case, it is marginal usage: The PCI transaction state machine is fiddly, but not overly complex. You can find a reference state machine diagram in the PCI 2.2 official spec.

A more serious concern is IO usage:

I/O Function:

    Type                                  | w/o register  | w/ register  | w/ DDR register
    --------------------------------------|---------------|--------------|----------------
    Input I/O                             | 16            | 0            | 0
    Output I/O                            | 8             | 0            | 0
    Bidirectional I/O                     | 36            | 0            | 0
    Differential Input I/O Pairs          | 0             | 0            | 0
    Differential Output I/O Pairs         | 0             | 0            | 0

I/O Technology:

                                    |   Voltages    |             I/Os
    --------------------------------|-------|-------|-------|--------|--------------
    I/O Standard(s)                 | Vcci  | Vref  | Input | Output | Bidirectional
    --------------------------------|-------|-------|-------|--------|--------------
    LVCMOS33                        | 3.30v | N/A   | 3     | 3      | 0
    PCI                             | 3.30v | N/A   | 13    | 5      | 36

And in particular, meeting timing with those IOs! Remember you have on the order of 40-50 IOs that need to be registered on the rising edge of 33MHz clock. If those IOs have to span IO banks, you may find meeting timing more difficult (especially on these 'vintage' FPGA devices.) You really want to make sure that all the PCI signals are on the same bank (although I imagine the dev board developers probably did their homework here.)